1

1. Uvod

EMRIS je metodologija, kar pomeni, da obsega:

opis procesa razvoja in

opis metod in tehnik, uporabljenih v različnih razvojnih fazah.

Slika 1.1: Na x-osi so predstavljene faze razvoja IS, na y-osi pa aktivnosti, ki se izvajajo v posameznih fazah procesa razvoja IS.

2

1.1 Metamodel EMRIS Metamodel je koncept, s pomočjo katerega predstavimo problemsko področje na konceptualni ravni. V njem nastopajo koncepti in gradniki, ter povezave med njimi. Metamodel EMRIS je predstavljen s pomočjo diagramske tehnike entitetnih diagramov.

1.1.1 Metamodel strateškega planiranja

Metamodel strateškega planiranja prikazuje povezave med izdelki strateškega plana in obravnavanimi elementi strateškega planiranja. Pomembnejši izdelki strateškega plana so:

analiza strateških elementov (Poslanstvo, Vizija, Cilji, Problemi, Usmeritve, Kritični dejavniki uspeha),

pregledni model,

analiza obstoječega stanja IS,

vpliv IT,

načrt IT in

plan razvoja IS. Pomembnejši koncepti obravnave v okviru izdelave strateškega plana so:

organizacijski sistem,

informacijski sistem,

funkcija,

delovni proces,

entiteta,

medorganizacijski proces,

poslovno pravilo,

projekt ter

informacijska tehnologija. Strateški elementi se nanašajo na organizacijski sistem ali na informacijski sistem. Funkcija organizacijskega sistema pripada enemu funkcionalnemu področju in sestoji iz več elementarnih funkcij, preko katerih tečejo delovni procesi. Funkcijo opravlja ena ali več odgovornih oseb. Organizacijski sistem se povezuje z zunanjimi organizacijskimi sistemi (s poslovnimi partnerji) preko medorganizacijskih procesov, ki za povezovanje uporabljajo povezovalno tehnologijo in informacijske vire. Poslovna pravila upravljajo/nadzirajo izvajanje delovnih procesov v organizacijskem sistemu in izvajanje medorganizacijskih procesov ter opredeljujejo pogoje, ki morajo biti v danem trenutku izpolnjeni, da se izvede določena akcija. Na izdelavo načrta IT vplivajo predhodno določeni cilji in kritični dejavniki uspeha (v nadaljevanju KDU). Plan razvoja IS določa prioriteto izdelave aplikacij in operativni plan projektov izdelave aplikacij. Iz plana razvoja navadno izhaja več projektov izdelave aplikacij, pri katerih sodelujejo zunanji in notranji izvajalci.

3

Slika 1.1.1: Metamodel strateškega planiranja

4

1.1.2 Metamodel strukturnega razvoja

Drugi metamodel opisuje povezave med obravnavanimi elementi strukturnega razvoja IS in izdelki, ki nastanejo pri tem razvojnem pristopu. Pomembnejši izdelki strukturnega razvoja so:

nova aplikacija,

programski modul,

podatkovna baza,

specifikacija,

API za povezavo z zunanjimi IS,

uporabniška dokumentacija in

strategija prehajanja na novo aplikacijo. Pomembnejši koncepti obravnave so:

zunanji IS,

produkcijsko okolje,

testno okolje,

standard razvoja,

CASE orodje,

izpis-poročilo,

meni, uporabnik ter uporabniški vmesnik.

Pri razvoju aplikacije sodelujejo notranji in zunanji izvajalci. V primeru prenovitve se za prehod iz stare na novo aplikacijo uporablja strategija prehajanja na novo aplikacijo. Obravnavani IS se povezuje z enim ali več zunanjih IS in za implementacijo povezovanja uporablja API. Nova aplikacija je razvita s pomočjo enega ali več orodij CASE in enega ali več drugih orodij. Za novo aplikacijo imamo testno okolje, uvajalno okolje in produkcijsko okolje. Novo aplikacijo vpeljemo v uporabo na podlagi potrditvenega testa.

5

Slika 1.1.2: Metamodel strukturnega razvoja IS

6

1.1.3 Metamodel objektnega razvoja IS

Kot tretji je predstavljen metamodel objektnega razvoja IS, ki predstavlja povezave med obravnavanimi elementi in izdelki pri tem razvojnem pristopu. Pomembnejši koncepti in izdelki objektnega razvoja so:

objektna tehnologija, objekt, razred objektov,

proces razvoja, procesni model,

metoda, aktivnost,

projekt (izdelki),

aplikacija (izdelek) in

uporabnik.

Glavni koncept objektne tehnologije je razred objektov, ki združuje enega ali več objektov. V okviru razreda objektov so določena dedna pravila in podrazredi. Vsak objekt ima lahko več stanj in lastnosti. Objektni proces razvoja, kot že ime pove, uporablja objektno tehnologijo, kakor jo uporablja tudi procesni model. Procesni model v bistvu določa proces razvoja, ki je sestavljen iz posameznih faz. Procesni model je skupek pravil, strategij, aktivnosti, metod, opravil in korakov, katerih namen je doseči poslovne cilje. Strategija izdelave programske opreme opisuje in narekuje širši pogled na izvajanje aktivnosti v procesu. Metoda je poseben način izvajanja aktivnosti (npr. strukturna analiza je metoda za izvajanje analize). Opravilo je poseben način uporabe metode v sklopu dane aktivnosti. Objektni proces razvoja, ki ga določa procesni model, mora biti voden projektno v okviru projekta izdelave aplikacije. Rezultat projekta izdelave aplikacije je delujoča aplikacija, ki je namenjena končnim uporabnikom.

7

Slika 1.1.3: Metamodel objektnega razvoja IS

8

1.1.4 Metamodel razvoja IS za upravljanje delovnih procesov

Zadnji metamodel opisuje tretji možni pristop k razvoju IS, ki ga priporoča EMRIS in se imenuje razvoj IS za upravljanje delovnih procesov.

Pomembnejši koncepti in izdelki razvoja IS za upravljanje delovnih procesov so:

!delovni proces,

!orodje za upravljanje delovnih procesov,

definicija-opis procesa (izdelek),

elementarna funkcija,

aktivnost,

delovni tok,

projekt (izdelki),

!uporabnik in

vloga. Delovni proces nekega OS (organizacijskih sistem) je sestavljen iz posameznih aktivnosti, katerih zaporedje se pri analiziranju procesa zapiše v definiciji ali opisu procesa. Razvoj IS za upravljanje delovnih procesov mora potekati v okviru projekta, ki izpolnjuje cilje in usmeritve OS.

9

Slika 1.1.4: Metamodel razvoja IS za upravljanje delovnih procesov

10

1.2 Povezovanje organizacijskih sistemov in uvajanje elektronskega

poslovanja V splošnem lahko elektronsko poslovanje opredelimo kot način delovanja, organiziranja ter notranjega in zunanjega sodelovanja organizacijskega sistema, ki je podprt z dosežki informacijskih in telekomunikacijskih tehnologij: aplikacijami, storitvami in tehnološko infrastrukturo.

Slika 1.2.: Informacijski sistem v širšem smislu – podpora elektronskemu poslovanju (IS se širi preko meja organizacijskega sistema)

1.2.1 Oblike in področja elektronskega poslovanja

Oblike elektronskega poslovanja se med seboj ločijo po akterjih, ki so vpleteni v poslovanje: posameznik, podjetje in državna uprava. Posameznik predstavlja generalizacijo in nastopa v odvisnosti od oblike poslovanja v več specializiranih vlogah: potrošnik (kupec), zaposleni in državljan.

Glede na akterje, so na področju državne uprave znane naslednje oblike elektronskega poslovanja:

G2G (government to government) in/ali O2O (office to office): akterji vpleteni v obravnavano obliko elektronskega poslovanja so enote v okviru državne uprave.

G2C (government to citizen): v obravnavani obliki elektronskega poslovanja gre za poslovanje med državno upravo in državljanom.

G2B (government to business): gre za obliko elektronskega poslovanja med državno upravo in poslovnimi sistemi.

11

Poleg tega obstajajo še bolj splošno znane oblike elektronskega poslovanja, ki so značilne za področje poslovnih sistemov:

B2B (business to business): gre za obliko elektronskega poslovanja med organizacijskimi sistemi.

B2C (business to customer): v obravnavani obliki elektronskega poslovanja sta vpletena organizacijski sistem in stranka.

B2E (business to employee): V obravnavano obliko poslovanja sta vpletena organizacijski sistem in zaposleni. Gre torej za interno obliko poslovanja.

Slika 1.2.1: Prikazan je G2G in G2C obliki elektronskega poslovanja. Na sliki sta dva tokova – prvi je tok informacij med organizacijskimi sistemi državne uprave (G2G), drugi pa predstavlja tok informacij med državno upravo in državljanom (G2C)

1.2.2 Usmeritve in cilji uvajanja elektronskega poslovanja v javno upravo RS

Usmeritve uvajanja elektronskega poslovanja:

zagotoviti enostaven, hiter, kakovosten in poceni dostop državljanom do informacij in storitev javne uprave s pomočjo sodobne ITkT

zagotoviti tako prijazne storitve javne uprave, da državljanom v postopkih ne bo potrebno priskrbeti podatkov, ki so jih nekoč, v neki življenjski situaciji, že podali

omogočiti dostop do vseh javnih podatkov

skrajšati odzivne čase na zahteve državljanov po storitvah javne uprave RS

vzpodbujati vse vidike e-poslovanja in možnosti dostopa do informacij in storitev javne uprave ter s tem višati splošni življenjski standard,

doseči kakovostnejše sodelovanje med javno upravo RS in uporabniki oz. prebivalci,

omogočiti večji pregled nad notranjim delovanjem javne uprave RS,

pospešiti prehod Slovenije v informacijsko družbo in

vzpostaviti e-demokracijo.

12

Cilji uvajanja elektronskega poslovanja so:

evidentirati in natančneje opisati vse postopke znotraj javne

povezati vse sedanje in bodoče informacijske sisteme, administrativne registre in druge zbirke podatkov javne uprave med seboj

določiti standarde, postopke in sisteme arhiviranja papirnih in elektronskih dokumentov

vzpostaviti ustrezne mehanizme varnosti za identifikacijo in avtentikacijo državljanov v postopkih javne uprave (pametna kartica, digitalni podpis),

implementirati pravila varovanja osebnih podatkov v postopkih in storitvah javne uprave

vzpostaviti enotni državni portal in pod-portale za vsa delovna področja javne uprave

omogočiti plačila davkov, upravnih taks, kazni in drugih terjatev, ki nastanejo iz opravljenih upravnih storitev,

organizirati izobraževanja za delavce javne uprave in za državljane o uporabi novih prijaznejših storitev javne uprave.

1.3 Agilni koncepti, pristopi in metodologija Prve metodologije razvoja informacijskih sistemov so nastale že v zgodnjih sedemdesetih letih (Codd, DeMarco, Booch,...). S tem, ko so uspeli prepričati strokovno javnost, da je potrebno tudi za področje razvoja IS urediti postopke, predpisati metode, tehnike in orodja, so ovrgli smiselnost uporabe ad-hoc pristopov.

1.3.1 Kaj je metodologija in zakaj jo potrebujemo?

Metodologija zajema vse, kar redno počnemo, da bi dosegli želen rezultat (izdelek ali storitev). V primeru razvoja programske opreme to ne pomeni zgolj postopkov, ki so neposredno povezani z razvojem (npr. analiza, načrtovanje), temveč zajema tudi podporne postopke, načine komunikacije med sodelujočimi, pravila odločanja in podobno. V tem oziru lahko metodologijo opredelimo tudi kot množico dogovorov (konvencij), s katerimi se projektna skupina/organizacija strinja. Kljub temu, da obstajajo številne metodologije, ki temeljijo na preizkušenih postopkih, ki so se v praksi izkazali kot dobri, si jih organizacije vedno prilagodijo po svojih merah. Metodologija zajema poleg formalno opredeljenih elementov, ki so zapisani v obliki postopkov, pravil, napotkov, smernic, standardov in podobno v navadnih ali elektronskih priročnikih, tudi številne druge nedokumentirane elemente. Posebno mesto med njimi nosi znanje, ki ga člani organizacije uporabljajo pri svojem delu ter izkušnje. V znanosti obstaja posebna veja, ki se ukvarja z znanjem (Knowledge Management) – namen je iskanje tehnik in metod za zajem, formalizacijo in prenos znanja. Znanje se deli na eksplicitno in skrito znanje. Eksplicitno je moč shraniti v neki formalni obliki, tacitno (skrito) pa je subjektivne narave in je prepleteno z izkušnjami, čustvi, intuicijo, zaradi česar ga je težko izraziti. Omenjen fenomen ima svoje mesto tudi na področju metodologij. Dokumentirana metodologija je sprva osnova, iz katere se uporabniki učijo in razvijejo svojo percepcijo o načinu dela, komunikaciji in odločanju. Skozi uporabo pridobivajo nove izkušnje in bogatijo svoje znanje, kar posledično vpliva tudi na metodologijo samo. Skratka, skozi uporabo se metodologija bogati na osnovi skritega znanja posameznikov. Iz njega se lahko sčasoma izkristalizirajo formalne oblike (metode, postopki, smernice, napotki) ter postanejo del formalne metodologije.

13

Slika 1.3.1.: Od neformalne do formalne metodologije

Meje med formalnim in neformalnim delom metodologije seveda ni enostavno postaviti. Metodologija je dinamična in se stalno spreminja. Zato postane problem, ker marsikatera podjetja se ne držijo popolnoma formalnih delov metodologije, saj če bi hoteli zapisati še vse neformalne, bi to vse skupaj ratalo zelo kompleksno, ogromno in komplicirano. Preobsežno neformalna metodologija je pa tudi tvegana za organizacijo, saj je popolnoma odvisna od njenih uporabnikov.

1.3.2 Agilni koncepti, pristopi in metodologije

Temelji agilnih metodologij so bili postavljeni decembra 2001, ko se je sestala skupina sedemnajstih gurujev, tako ali drugače znanih s področja lahkih metodologij (Extreme programming, Feature-driven development, Scrum,...). Namen sestanka je bil ugotoviti, kaj imajo »njihove« metodologije skupnega in na osnovi tega postaviti skupne metodološke osnove. V skupni izjavi so člani zveze kot njihov cilj zapisali »iskanje boljših pristopov razvoja programske opreme, tako da pri tem sami sodelujejo in pomagajo drugim.« Iz tega so izpeljali štiri načela:

Posamezniki in njihova komunikacija so pomembnejši kot sam proces in orodja. Dobra komunikacija je ključna za uspešnost projekta.

Delujoča programska oprema je pomembnejša kot popolna dokumentacija. Dokumentirane zadeve so vsekakor koristne, vendar naročnik ne bo zadovoljen s

kupom dokumentacije, če ne bo najprej videl delujočega izdelka.

Vključevanje (sodelovanje) uporabnika je pomembnejše kot pogajanje na osnovi pogodb. Naročnik ponavadi najbolje ve, kaj potrebuje, čeprav tega pogosto ne zna razložiti.

Zato je pozornost posvečena odnosu med naročnikom in izvajalcem.

Upoštevanje sprememb je pomembnejše od sledenja planu. Projektni plani so koristen element, vendar morajo omogočati spremembe, vsaj v

smislu preureditve prioritet znotraj dogovorjenega okvirja.

14

Iz načel, ki veljajo kot osnova agilnih metodologij, so izpeljana številna priporočila, ki so v pomoč pri gradnji in vrednotenju metodologij:

Najvišja prioriteta je zadovoljstvo naročnika, zato je priporočeno zgodnje in pogosto izdajanje komponent preizkušene in delujoče programske opreme.

Delujoče komponente programske opreme je potrebno izdajati pogosto, v ciklu, ki ni daljši od štirih mesecev.

Spremembe v zahtevah naj bodo dobrodošle tudi v poznih fazah razvoja. Eno izmed načel agilnih pristopov je dober odnos med naročnikom in izvajalcem. Spremembe, ki nastanejo med projektom, in smo jih pripravljeni upoštevati, lahko prinesejo naročniku pomembno konkurenčno prednost, zato se jih ne smemo otepati. Iterativni pristop se tudi na tem mestu izkaže kot primeren.

Projekti naj vključujejo motivirane posameznike.

Najboljši način prenosa informacij do in med člani projekta je komunikacija »iz oči v oči«.

Kakovost programske kode in arhitekture je potrebno stalno preverjati in izboljševati.

Enostavnost procesa je ključ do uspeha. Kako razviti kakovostno programsko opremo, pri tem pa opraviti čim manj stranskih nalog in izdelkov? Proces mora biti ravno dovolj zahteven. Raje malo manj kot pa preveč. To nikakor ne pomeni, da moramo aktivnosti izvajati površno ali pomanjkljivo. Nasprotno, naše delo mora biti opravljeno kvalitetno, paziti pa moramo, da ni po nepotrebnem komplicirano. Pot do enostavnosti je v resnici težka, saj je včasih preprosteje pustiti stvari kompleksne, kot jih pa poenostaviti.

Po vsakem intervalu (iteraciji) moramo preveriti proces, ki smo ga uporabljali, ugotavljamo, kaj je bilo pri tem dobrega in kaj odveč. Glede na ugotovitve proces prilagodimo in izboljšamo za naslednje iteracije.

1.3.3 Agilnost in EMRIS

Namen predstavitve konceptov agilnosti in agilnih pristopov je opozoriti na potrebo po oblikovanju in prilagajanju referenčne metodologije potrebam, značilnostim in zahtevam vsakega posameznega projekta posebej. Vsakemu projektu posebej je potrebno prilagoditi metodologijo in jo preko mehanizmov prilagajanja umestiti med enostavno in rigorozno metodologijo

15

1.4 Evaluacija metodologije Na podlagi evaluacije lahko izberemo ustrezno metodologijo, oziroma že obstoječo prilagodimo značilnostim projekta in razvojne skupine.

1.4.1 Zgradba metodologij kot osnova za evaluacijo

Osrednji element metamodela je metodologija, ki je sestavljena iz filozofije, procesa, tehnik, standardov, orodij ter uporabnosti in izkušenj z metodologijo. Filozofijo metodologije sestavlja paradigma, cilji, domena, ozadje, namen in sociološka komponenta metodologije. Proces je agregat življenjskih ciklov, izdelkov, vlog in aktivnosti s pripadajočimi opravili. Aktivnosti so sestavljene iz opravil, v okviru katerih nastajajo izdelki, ki so v tem primeru izhod iz aktivnosti. Na drugi strani so lahko izdelki tudi vhod v opravilo. Opravilo izvaja ena ali več vlog, ki potrebujejo ustrezne izkušnje in znanje. V odvisnosti od tipa življenjskega cikla procesa, lahko v okviru procesa nastopajo tudi faze, iteracije in inkrementi. Metodologija uporablja tudi več različnih tehnik. Tehnike lahko nastopajo v okviru opravil (npr. programiranje v parih kot tehnika dela z ljudmi) ali pa gre za tehnike na podlagi katerih nastanejo izdelki (npr. jezik UML kot tehnika modeliranja). Nekatere tehnike so podprte tudi z orodji, ki omogočajo izdelavo posameznih izdelkov. Metodologija lahko predpisuje tudi različne standarde. Zadnji sestavni del metodologije je uporabnost in izkušnje z metodologijo. V okviru tega se sprašujemo kakšno izobraževanje je na voljo in kako kakovostno je. Prav tako je pomembna baza uporabnikov (število uporabnikov, vrste organizacij, ki metodologijo uporabljajo). Omenimo še, da morajo biti posamezni elementi metodologije medsebojno usklajeni, saj se med seboj prepletajo in so močno povezani drug z drugim.

16

1.4.2 Delitev glede na tip metodologije

Gre za delitev na podlagi filozofije metodologije.

Cilj socio-tehničnih metodologij ni nujno programska rešitev, ampak je lahko tudi samo organizacijska. Metodologije pri katerih je poudarek na organizacijski rešitvi uvrščamo med organizacijsko usmerjene, metodologije pri katerih je poudarek na sociološki komponenti pa med metodologije usmerjene v človeka. Med tehnične metodologije uvrščamo preostale tipe metodologij, katerih glavni cilj je izgradnja programske rešitve. Procesno usmerjene metodologije uporabljajo predvsem procesne in strukturne tehnike ter slapovni (zaporedni) življenjski cikel. Namesto življenjski cikel včasih uporabljamo tudi izraz model, torej: zaporedni model. Podobno velja tudi za podatkovno-procesne metodologije, pri katerih je dodatno še poseben poudarek na podatkovnih tehnikah. Objektno usmerjene metodologije uporabljajo predvsem objektne tehnike. Za njih je značilna uporaba iterativnega in inkrementalnega razvoja. Poleg tega pogosto vključujejo tudi izdelavo prototipov. Objektno usmerjene metodologije vključujejo tudi podatkovne tehnike, ki jim omogočajo uporabo relacijskih podatkovnih baz.

Zadnja skupina so metodologije za hiter razvoj. Te metodologije temeljijo na posebnih tehnikah dela z ljudmi (npr. JAD, programiranje v parih). Za njih je značilna uporaba iterativno-inkrementalnega življenjskega cikla pa tudi prototipiranja. Sicer lahko take metodologije uporabljajo tudi podatkovne, procesne in objektne tehnike (to na diagramu ni prikazano).

17

Procesno usmerjene metodologije temeljijo na modeliranju dogajanja v sistemu. Pri tem uporabljajo vrsto procesnih tehnik kot so diagrami podatkovnih tokov, odločitvena drevesa in akcijski diagrami. Poleg tehnik modeliranja procesov vključujejo tudi tehnike, ki omogočajo prikaz razgradnje in strukture sistema, kot npr. strukturni diagrami (funkcionalna razgradnja). Večinoma uporabljajo slapovni model z modifikacijami. Podatkovno-procesne (mešane) metodologije do neke mere nadgrajujejo procesno usmerjene, saj poleg modeliranja procesov sistema, vključujejo tudi modeliranje podatkov, ki v sistemu nastopajo. Tehnike, ki jih uporabljajo mešane metodologije torej vključujejo procesne tehnike (vključno s strukturnimi) in tehnike podatkovnega modeliranja. Večinoma uporabljajo slapovni model z modifikacijami. Objektno usmerjene metodologije se bistveno razlikujejo od procesno in podatkovno-procesno usmerjenih metodologij. V teh metodologijah ima osrednjo vlogo modeliranje objektov. Pri objektno usmerjenih metodologijah ne gre le za drugačen pristop k analizi in načrtovanju, ampak je potrebna tudi uporaba drugačnih (objektno usmerjenih) programskih jezikov in orodij. Osnovna ideja objektne tehnologije je izgradnja sistemov na osnovi obstoječih, že preizkušenih gradnikov. Objektni proces razvoja IS je sestavljen iz več faz. Znotraj posameznih faz izvajamo aktivnosti, te pa bolj natančno delimo na opravila. Osnovno vodilo objektnega procesa razvoja IS je naravnanost na iterativen in inkrementalen življenjski cikel. Pri tem posamezne izdelke izdelujemo v več iteracijah, v vsaki iteraciji pa temeljimo na izdelkih predhodnih iteracij, ki jih dopolnimo in nadgradimo. Za modeliranje in specificiranje izdelkov objektno usmerjenih metodologij, so se proti koncu 1990ih let uveljavile standardizirane tehnike UML. Metodologije za hiter razvoj (RAD) temeljijo predvsem na iterativnem življenjskem ciklu in prototipiranju. Te metodologije temeljijo na uporabi orodij za hiter razvoj programske opreme (npr. programska okolja RAD). Navadno uporabljajo posebne tehnike dela z ljudmi kot npr. JAD (Joint Application Design), programiranje v parih in druge tehnike. Metodologije RAD dajejo večji poudarek implementaciji in testiranju, manjši pa analizi in načrtovanju, v okviru katerega uporabljajo različne tehnike, tako procesne in podatkovne kot tudi objektne. Metodologije usmerjene v človeka uporabljajo socio-tehnični pristop. Torej pri razvoju programske opreme ne upoštevajo le tehnične komponente pač pa tudi sociološko. Pomembna lastnost teh metodologij je vključevanje vseh, na katere bo programska rešitev (sistem) vplivala, v proces odločanja o načrtu in delovanju sistema. Metodologije usmerjene v človeka pogosto vključujejo tudi lastnosti organizacijsko usmerjenih metodologij, saj navadno modelirajo celotno organizacijo. Ideja organizacijsko usmerjenih metodologij je modelirati organizacijo kot celoto. Rezultat dela po taki metodologiji je lahko le organizacijska rešitev, ki poleg organizacijske vključuje tudi programsko rešitev. Organizacijsko usmerjene metodologije pogosto vključujejo tudi lastnosti metodologij usmerjenih v človeka (sociološka komponenta). Za modeliranje organizacije poleg organizacijskih tehnik pogosto uporabljajo podobne tehnike kot podatkovno in procesno usmerjene metodologije, nekatere pa uporabljajo tudi tehnike objektno usmerjenih metodologij.

18

1.4.3 Delitev glede na težo metodologije

Obseg metodologije je določen s številom različnih elementov, ki jih metodologija opisuje. Govori na primer o tem, katere aktivnosti neka metodologija obsega, katere vloge so v njej opisane, katere izdelke in standarde vključuje ipd.

Gostoto metodologije lahko definiramo kot zahtevan nivo podrobnosti oziroma formalnosti. Metodologije z višjo gostoto so bolj formalne, njihovi elementi pa so opisani do višje stopnje podrobnosti. Metodologije z nižjo gostoto več prepuščajo interpretaciji posameznika, ki metodologijo uporablja. Težo lahko definiramo kot zmnožek obsega in gostote.

Lahke metodologije uporabimo v primeru, ko:

je glavni cilj razvoj programske rešitve,

imamo odgovorne, disciplinirane, izkušene in motivirane razvijalce, ki so seznanjeni s posebnimi tehnikami dela,

imamo stranko, ki razume bistvo lahkih metodologij in je pripravljena sodelovati,

imamo nepredvidljive in spreminjajoče se zahteve za programsko rešitev,

je cilj razvoja relativno majhen sistem z nižjo stopnjo kritičnosti, ki ga je mogoče razviti z majhno razvojno ekipo.

Za lahke metodologije torej lahko rečemo, da so metodologije z manjšim obsegom in manjšo gostoto in so relativno visoko prilagodljive in da temeljijo na izkušnjah, discipliniranosti in razumevanju. Čim lažja je metodologija, tembolj prilagodljiva in manj optimizirana je.

19

Težke metodologije so metodologije z večjim obsegom in večjo gostoto. Podrobno opisujejo izdelavo dokumentacije in pogosto predpisujejo tudi uporabo določenih orodij in tehnik. Za težke metodologije lahko rečemo, da so relativno visoko optimizirane in da temeljijo na procesu, formalnosti in dokumentaciji. Čim težja je metodologija tembolj optimizirana in manj prilagodljiva je. Težke metodologije uporabimo kadar:

cilj ni le razvoj programskega sistema ampak tudi prenova organizacijskega sistema,

imamo manj izkušene razvijalce, pri katerih točno opredeljena formalna pravila nadomeščajo izkušnje in znanje,

naročnik zahteva visoko stopnjo formalizma (izdelovanje dokumentacije),

imamo relativno dobro definirane in stabilne zahteve,

je cilj razvoja obsežnejši sistem z višjo stopnjo kritičnosti, ki zahteva izdelavo ustreznih načrtov in dokumentacije.

1.4.4 Delitev glede na utežitev metodologije

Ideja o delitvi metodologij glede na njihovo utežitev izhaja iz zaporedja izvajanja aktivnosti razvoja programske opreme. Tako najprej izvajamo analizo in načrtovanje, nato pa kodiramo in testiramo. Metodologije, ki dajejo poudarek prvima aktivnostma označimo kot spredaj utežene, metodologije, ki dajejo poudarek drugima aktivnostma pa lahko opredelimo kot zadaj utežene. Metodologije, ki dajejo pri razvoju nekaterih delov sistema poudarek prvim in pri drugim aktivnostim (odvisno od značilnosti posameznih delov sistema) pa označimo kot uravnotežene metodologije. Teoretično velja, da niti teža niti tip metodologije nista neposredno povezana z njeno utežitvijo. V praksi pa se izkaže, da so spredaj utežene metodologije navadno težke metodologije, zadaj utežene pa so pogosto lahke metodologije. Spredaj utežene metodologije (frontloaded) dajejo poudarek postopkom analize in načrtovanja, ki jih v veliki meri izvedejo vnaprej. Rezultat izvajanja teh postopkov so do podrobnosti opredeljene zahteve za sistem, izdelani natančni načrti in podobno. Take metodologije so primerne za razvoj:

sistemov s stabilnimi zahtevami: Zahteve morajo biti dobro specificirane in stabilne.

kritičnih sistemov: Pri kritičnih sistemih je dobra analiza in načrtovanje ključnega pomena. Pri tem moramo predvideti tudi čimveč možnih alternativnih scenarijev dogajanja (alternativni dogodki, napake), ki jih zajamemo že v načrtu.

obsežnih in kompleksnih sistemov, z velikimi razvojnimi skupinami: Kadar imamo opravka z veliko razvojno skupino, so potrebni bolj podrobni načrti, ki omogočajo usklajevanje in razdeljevanje dela med člani.

Med spredaj utežene metodologije lahko uvrstimo večino klasičnih metodologij. Glavna kritika teh metodologij je, da preveč časa posvečajo analizi in načrtovanju, rezultat pa je načrt, ki zaradi hitrega spreminjanja zahtev ni uporaben. Pomembna kritika je tudi, da zvesto sledenje takim metodologijam lahko pomeni podrobno definiranje stvari, ki jih še ne poznamo dovolj dobro oziroma, ki jih bomo spoznali šele v poznejših fazah razvoja (npr. šele v izvedbi).

20

Zadaj utežene metodologije (backloaded) dajejo prednost postopkom izvedbe in testiranja. Analiza in načrtovanje sta potisnjena v ozadje, izdelani so morda le osnovni načrti, ki se ne ukvarjajo s podrobnostmi. Razvijalci se takoj pričnejo ukvarjati s kodiranjem, pri čemer analizirajo zahteve in načrtujejo sistem kar sproti. Zadaj utežene metodologije so se pojavile šele s prihodom uporabnih orodij RAD, ki omogočajo relativno hitro in ceneno odpravo napak tudi v izdelanem sistemu.

Slika 1.4.4: Naraščanje cene spremembe (odprave napake) s časom po klasičnem modelu in modelu RAD

Pri klasičnem modelu napaka (sprememba) odkrita v implementaciji pomeni tudi spremembo načrta, analize in podobno. Pri modelu RAD cena napake s časom ne raste eksponentno. Razlog za to je, da lahko z uporabo dobrih orodij RAD napako odpravimo relativno hitro in poceni. Zadaj utežene metodologije so primerne za razvoj:

manjših in bolj enostavnih sistemov, z majhnimi in izkušenimi razvojnimi skupinami.

sistemov s slabo določenimi zahtevami, ki se bodo najverjetneje še spreminjale.

nekritičnih sistemov; Posledica manj podrobne analize in načrtovanja bo tudi manj stabilna arhitektura, ki ni primerna za kritične sisteme. Hkrati je take sisteme pozneje težje nadgrajevati in vzdrževati.

sistemov, ki uporabljajo tehnologijo s katero nismo seznanjeni. V primeru, da ne poznamo tehnologije, lahko z uporabo zadaj utežene metodologije tehnologijo preizkusimo in spoznamo.

Med take pristope bi lahko uvrstili metodologije, ki temeljijo na prototipiranju kot življenjskem ciklu razvoja.

Uravnotežene metodologije (balanced) dopuščajo, da na eni strani, za tiste dele sistema za katere so zahteve dobro znane in stabilne, izvedemo podrobnejšo analizo in na drugi strani, za dele sistema, ki jih še ne poznamo dovolj dobro, pričnemo s kodiranjem in testiranjem (npr. izdelava prototipov), ki nam pomaga pri podrobnejšem določanju zahtev. Gre torej za to, da nekatere aktivnosti izvajamo na »spredaj utežen način«, druge pa na »zadaj utežen način«. Kljub temu, da se morda na prvi pogled zdi, da so uravnotežene metodologije idealna izbira za vse primere, pa to ne drži. Potrebno se je zavedati, da uteženi procesi nimajo niti vseh značilnosti spredaj, niti vseh značilnosti zadaj uteženih procesov. Tako je na primer uporaba spredaj uteženega procesa v primeru kritičnega sistema z dobro definiranimi zahtevami bolj ustrezna kot uporaba uravnoteženega.

21

1.4.5 Ocenjevanje in izbira metodologij na podlagi agilnih principov

Poznamo 7 t.i. agilnih principov za izbiro in ocenjevanje metodologij. V kolikor metodologija ustreza naštetim kriterijem jo lahko opredelimo kot agilno. 1. Neposredna komunikacija »iz oči v oči« je najhitrejši in najcenejši kanal za izmenjavo

informacij.

Značilnost neposredne komunikacije je, da je navadno bolj osebna ter da v primerjavi s posredno uporablja več različnih komunikacijskih kanalov (npr. video in avdio kanal) za prenos istega sporočila.

Komunikacijo lahko, poleg delitve glede na njeno (ne)posrednost, razdelimo tudi glede na njeno usmerjenost. Tako je lahko komunikacija enosmerna (npr. knjiga, video) ali pa dvosmerna (npr. pogovor, e-pošta).

Neposredna komunikacija je bolj učinkovita od posredne, hkrati pa je tudi dvosmerna komunikacija bistveno bolj učinkovita od enosmerne.

Prvi princip torej predvideva, da je komunikacija učinkovitejša v skupini ljudi, ki so blizu in

imajo pogoste kontakte.

Posledica je hitrejši, cenejši in bolj učinkovit razvoj programske opreme.

Ker takšna neposredna komunikacija iz oči v oči ni mogoča pri večjih skupinah (tako bi namreč preveč časa porabili samo s komunikacijo), je smiselno uvesti manjše podskupine, kjer je pa taka komunikacija zelo uspešna.

Neposredno obliko komunikacije torej velja uporabiti tam, kjer je to mogoče in smiselno.

22

2. Nepotrebna dodatna teža metodologije je draga.

Metodologija naj opredeljuje le toliko elementov kot je to potrebno.

Slika prikazuje učinek povečevanja teže metodologije v majhni razvojni skupini.

Nepotrebna teža niža storilnost in s tem tudi velikost problema, ki ga lahko skupina obvlada.

3. Večje razvojne skupine za svoje delovanje potrebujejo težje metodologije.

S povečevanjem razvojne skupine se manjšajo možnosti za neposredno komunikacijo med člani razvojne skupine. Zato je potrebno pomanjkanje neposredne komunikacije nadomestiti s tem, da metodologiji dodajamo nove elemente, ki omogočajo posredno komunikacijo. Gre za elemente kot so npr. dodatni vmesni izdelki, na podlagi katerih lahko člani velike razvojne skupine usklajujejo svoje delo.

Slika prikazuje učinek večanja teže metodologije v veliki razvojni skupin.

Začetno povečevanje teže metodologije veča učinkovitost skupine, saj je v veliki skupini le z ustrezno stopnjo formalnosti mogoče doseči učinkovito koordinacijo. Vendar teže metodologije ni mogoče povečevati v nedogled, saj storilnost tudi v veliki ekipi zaradi preobremenjenosti z izvajanjem težke metodologije prične padati.

Ugotovitev, da uporaba pretežke metodologija onemogoči delovanje razvojne skupine je ena izmed pomembnejših kritik težkih metodologij.

23

4. Višja stopnja formalnosti metodologije je primerna za projekte z višjo stopnjo kritičnosti

Kritičnost sistema definiramo kot stopnjo škode, ki jo odpoved sistema potencialno povzroči.

Bolj kritični sistemi zahtevajo metodologije z večjo težo.

Cockburn definira štiri različne stopnje kritičnosti: izguba udobja: ob odpovedi ne nastane večja škoda oz. škodo je mogoče odpraviti

brez bistvenih finančnih ali drugačnih posledic (primer: računalniške igre) izguba nadomestljivega denarja: gre za napake, ki jih je moč odpraviti, četudi so v

to vpletene večje vsote denarja (primer: recimo pri banki, če se zmotimo pri transakciji, je to mogoče preklicati preko telefona, kar pa sicer nekaj stane)

izguba nenadomestljivega denarja: posledica je lahko tako huda, da gre podjetje v stečaj (primer: del programske opreme za banke)

izguba življenja: primer: programska oprema za krmiljenje jedrske elektrarne, kontrola letalskega prometa, ABS, airbags,...)

Velja torej, da v primeru višje kritičnosti sistema (projekta) uporabimo težjo (predvsem bolj gosto) metodologijo.

5. Boljša komunikacija in več povratnih informacij zmanjšuje potrebo po vmesnih izdelkih.

Vmesni izdelek je izdelek, ki ostaja znotraj razvojne skupine in je namenjen razvijalcem, ki na njegovi podlagi razvijajo sistem.

Število takih izdelkov je možno znižati na dva načina: s hitro izdelavo delujočega dela sistema, ki omogoča, da zgodaj preverimo ali so

zajete zahteve ustrezne, dobimo več povratnih informacij, česar posledica je, da nekaterih vmesnih izdelkov ne potrebujemo,

z zmanjšanjem razvojne skupine ter namestitvijo vseh njenih članov v skupen prostor, s čimer dvignemo raven neposredne komunikacije, kar ponovno pomeni manjšo potrebo po vmesnih izdelkih.

Pri zgoraj navedenih vmesnih izdelkih je potrebno upoštevati, da gre za interne izdelke – torej tiste, ki jih potrebujejo le razvijalci. Še vedno pa je potrebno izdelati vmesne izdelke, ki jih je eksplicitno zahteval naročnik.

6. Čim večji so discipliniranost, izkušnje in znanje razvojne skupine, tem manjša je potreba po

podrobno definiranem procesu, formalnosti in dokumentaciji.

Proces, formalnost in dokumentacija so vsekakor pomembni. Vendar so discipliniranost, izkušnje in znanje pomembnejši.

Proces ni enako kot disciplina: Izdelki razvijalca, ki si je prostovoljno izbral skladen in discipliniran način dela, bodo bistveno boljši kot izdelki razvijalca, ki le sledi ukazom.

Formalnost niso izkušnje: Ne glede na to, koliko dokumentacije izdelamo, ta ne more nadomestiti izkušenj.

Dokumentacija ni enako kot znanje: V primeru, ko se zamenjata projektni skupini, predhodna s seboj odnese precej tacitnega znanja, ki ga ni mogoče zajeti v še tako dobri dokumentaciji.

Metodologije, ki temeljijo na disciplini, izkušnjah in znanju so bolj prilagodljive, njihova gostota pa je nižja.

Lahke metodologije so primerne za okolja, v katerih pogosto prihaja do sprememb (temeljijo na disciplini, izkušnjah in znanju), težke pa za okolja, v katerih ni veliko sprememb in zahtevajo bolj optimiziran proces (proces, formalnost in dokumentacija).

24

7. Odkloni od načrtovane rešitve nas vodijo k pravi rešitvi.

V kompleksnem okolju je rezultat sledenja načrtu načrtovan izdelek, ki pa ni enak izdelku, ki ga potrebujemo.

Tradicionalno mišljenje je, da so odkloni od načrtovane rešitve napake, ki jih je potrebno odpraviti. Pri agilnem pristopu pa odkloni niso obravnavani kot napake, ampak nekaj kar nas vodi k pravi rešitvi.

Ta princip je še posebno pomemben v okoljih s pogostimi spremembami, v katerih brez

prilagajanja odklonom prvotni načrt hitro zastara, rešitev izdelana na podlagi takega načrta pa je neuporabna.

1.4.5 Razvoj in vzdrževanje informacijskih sistemov

Spremembe so stalnica v razvoju informacijskih sistemov. Govorimo lahko o naslednjih vrstah sprememb:

spremembe delovnih procesov in pojav novih delovnih procesov,

spremembe poslovnih pravil in pojav novih poslovnih pravil,

spremembe v okoljih, s katerimi opazovani organizacijskimi sistem sodeluje in se jim mora prilagoditi ter

spremembe na področju informacijskih tehnologij, predvsem pojav novih.

Pojav vsake izmed teh sprememb pomeni poseganje v trenutni IS. Izvajanje teh posegov so temeljnje naloge in cilj vzdrževanja. EMRIS opredeljuje vzdrževanje kot fazo v okviru razvoja IS, ki nastopi po vpeljavi informacijskega sistema v uporabo oz. po zaključku faze vpeljave. Glavne naloge vzdrževanja so:

zbiranje zahtev po spremembah in dopolnitvah,

nadziranje in spremljanje delovanja informacijskega sistema,

izvajanje sprememb in dopolnitev,

spremljanje izvajanja sprememb in dopolnitev ter

ažuriranje uporabniške in sistemsko-tehnične dokumentacije skladno glede na spremembe in dopolnitve.

Praksa je v več primerih pokazala, da je lahko kontinuiteta kakovosti razvoja informacijskega sistema zagotovljena le v primeru, ko vse faze razvoja izvaja isti izvajalec. Predvsem je pomembno, da se izvajalec ne zamenja pri prehodu v fazo vzdrževanja. EMRIS zato priporoča, da celoten razvoj, tudi vzdrževanje kot fazo v okviru razvoja, izvaja en izvajalec, saj to zagotavlja najvišjo stopnjo enotnosti podpore izvajanja razvojnih aktivnosti in opravil.

25

2 Predstavitev strateškega planiranja To poglavje predstavlja pojem strateškega planiranja, cilje strateškega planiranja, proces izdelave strateškega plana ter ključne vloge pri projektu izdelave strateškega plana.

2.1 Uvod Po EMRIS se razvoj začne z izdelavo strateškega planiranja. Strateški plan vsebuje:

strateške elemente (poslanstvo, vizijo, cilje, usmeritve, probleme, KDU),

pregledni model organizacijskega sistema (organizacijsko shemo, globalni funkcionalni model, globalni model podatkovnih tokov, globalni model delovnih procesov, globalni podatkovni model, model uporabe mobilnih aplikacij in model povezovanja),

analizo obstoječega stanja IS,

vpliv IT,

načrt IT in

plan razvoja IS. Strateško planiranje traja praviloma od 3 do 6 mesecev, odvisno od velikosti in kompleksnosti OS (organizacijski sistem). Pri izvedbi projekta je potrebno sodelovanje zunanjih svetovalcev, ki so specialisti na posameznih področjih. Priporočena je uporaba visoko avtomatiziranih računalniško podprtih orodij. Glavno breme pri izvedbi nosijo metodologi, ki prihajajo iz vrst informatikov, praviloma zaposleni zunaj OS. Pri strateškem planiranju sodelujejo še ključni uporabniki in člani vodstvene strukture, ki s svojim znanjem o ciljih, aktivnostih in podatkih v OS nenadomestljivo prispevajo h kakovosti strateškega plana.

2.1.1 Povezava strateškega planiranja z razvojem IS

Povezanost med strateškim planiranjem in razvojem IS lahko opredelimo z izdelki, ki nastanejo pri strateškem planirajnu v okviru ene izmed aktivnosti. trateško planiranje tako razdelimo na pet aktivnosti:

Analiza obstoječega stanja,

Opredelitev poslovnih zahtev,

Opredelitev tehnoloških zahtev,

Planiranje informacijskega sistema in

Izdelava dokumentacije. Ko je strateško planiranje končano, se odločimo za razvoj IS z uporabo enega od treh možnih pristopov k razvoju:

strukturni razvoj IS,

objektni razvoj IS in

razvoj IS za upravljanje delovnih procesov. Odločitev za enega od treh možnih pristopov pa je odvisna predvsem od obstoječe informacijske infrastrukture, razvijalca IS, naročnika ter končnih uporabnikov.

26

Slika 2.1.1: Povezava strateškega planiranja z razvojem IS

27

2.1.2 Cilji strateškega planiranja

Strateško planiranje razvoja IS obravnavamo kot samostojen projekt, v okviru katerega želimo doseči nekatere pomembne cilje organizacijske in informacijske narave. Cilje strateškega planiranja lahko strnemo v naslednje točke:

Povezati razvoj IS s poslovno strategijo OS

Izboljšati komunikacijo med vodstveno strukturo in informatiki

Načrtovati pretok informacij in potek delovnih procesov

Učinkovito razporediti človeške vire

Zmanjšati stroške in skrajšati čas, ki je potreben za razvoj

Predlagati optimalno zaporedje nadaljnjih korakov pri planiranju in razvoju IS

Pripraviti vsa potrebna izhodišča, ki bodo služila kot pomoč pri nadaljnjih korakih informatizacije vse do izdelave aplikativnih sistemov.

Uporabiti standarde za enotne tehnološke rešitve

Pokazati na organizacijske probleme pri uvajanju informacijske podpore in predlagati organizacijske rešitve, ki bi imele za posledico racionalnejšo uporabo informacijske podpore.

Pri izdelavi strateškega plana obravnavamo naslednje koncepte:

poslanstvo, vizijo, cilje, usmeritve, probleme in KDU,

organizacijske enote, geografske lokacije,

funkcionalna področja, funkcije in delovne procese,

poslovna pravila (določa način za dosego enega ali več ciljev),

entitete,

zunanje organizacijske sisteme, zunanje informacijske sisteme in vmesnike,

strojno računalniško opremo, komunikacijsko opremo, programsko opremo, aplikacije ter

kadre.

28

2.1.3 Obseg strateškega planiranja

Največkrat se pri strateškem planiranju izdela strateški plan za celoten OS. V primerih, ko je nek OS sestavljen iz več podsistemov, ki imajo med seboj zelo šibke povezave, se lahko izdelajo tudi ločeni strateški plani za vsak podsistem. Pogosto se pojavljajo težnje za omejevanje obsega strateškega plana na nekaj manjšega, kot je celoten OS. Razlogov za tako ravnanje je več:

celoten OS se zdi prevelik in preveč kompleksen,

različni deli se ukvarjajo z različno dejavnostjo in

različni deli imajo različen pristop k vodenju.

2.1.4 Vključenost vodstvene strukture

Razvijalci IS se pogosto pritožujejo, da vodstvene strukture ne morejo dovolj pritegniti v strateško planiranje. Razlog je običajno preprost: pristop razvijalcev je preveč tehnično naravnan. Tehnike, ki se uporabljajo pri EMRIS - Strateško planiranje, se ukvarjajo s temami, ki so zelo blizu vodstveni strukturi, zato praviloma nimamo težav z zagotavljanjem njihovega sodelovanja, če le obstaja motivacija. Strateškega planiranja in sploh celotnega razvoja po EMRIS ni mogoče izpeljati brez popolne podpore vodstvene strukture. Običajno ustreznega sodelovanja oseb ni mogoče zagotoviti, če vodstvo ne izrazi podpore projektu.

2.1.5 Zunanji svetovalci

Visoko usposobljeni zunanji svetovalci lahko pogosto bolj jasno gledajo na organizacijske težave in so bolj inovativni pri iskanju novih možnosti, kot notranje osebe, saj te porabijo veliko energije za reševanje specifičnih problemov. Naloge, z uporabo posamezne tehnike, najbolj učinkovito izvedejo skupine, ki imajo mešano sestavo. Nekaj je zunanjih svetovalcev, ki so izvedenci za uporabo izbranih tehnik, drugi pa so notranji analitiki, ki dobro poznajo OS in imajo zaupanje vodstvene strukture

2.1.6 Metodološki pripomočki

EMRIS pri strateškem planiranju priporoča nekaj učinkovitih metod za zajemanje podatkov, kot so: intervjuji, delovni sestanki, delo na osnovi obstoječe dokumentacije. V tem delu gradiva se bomo osredotočili na intervjuje, za katere EMRIS priporoča že pripravljene vprašalnike, ki ob izkušenih zunanjih svetovalcih in sogovornikih zagotavljajo pridobitev kakovostnih in popolnih podatkov, ki odražajo dejansko stanje OS. Pri izvedbi intervjujev kot pripomoček uporabljamo Vprašalnik za pridobitev podatkov o strateških elementih, ki je razdeljen na dva dela:

Strukturirana vprašanja: ta del vprašalnika zajema 40 strukturiranih vprašanj, ki so pretežno zastavljena tako, da že vnaprej ponujajo možne odgovore (da/ne, ocene z lestvice od 1 do 5), nekaj pa je tudi naštevnih vprašanj. Z njimi poleg splošnih vsebin kot so najpomembnejše poslovne funkcije, najpomembnejše informacije in podobno, zajamemo pogled intervjuvanca na OS, obstoječi IS in razvoj informatike v prihodnosti.

Opisna vprašanja: ta del vprašalnika je namenjen pridobitvi še dodatnih informacij o organizacijskem in informacijskem sistemu, ki jih intervjuvanec ni uspel izraziti preko strukturiranega dela in se nanašajo na usmeritve, cilje, probleme, KDU in poslovna pravila organizacijskega ali informacijskega sistema.

Poleg vprašalnikov, ki jih uporabljamo pri izvedbi intervjujev, se pri strateškem planiranju uporabljata še Vprašalnik za pridobitev podatkov o obstoječem stanju IT in kadrih, ter Vprašalnik za pridobitev podatkov za oceno ustreznosti obstoječih aplikativnih sistemov.

29

2.1.7 Plan razvoja IS

Strateški plan običajno razkrije potrebe, ki bi jih bilo potrebno udejanjiti takoj, še preden je analiza funkcionalnega področja popolnoma zaključena. To so običajno kritični sistemi za podporo odločanju in poslovodni (direktorski) IS. Hitra in groba izvedba takih sistemov je mogoča s pomočjo preprostih orodij, kot so elektronske preglednice, s pomočjo programske opreme za sisteme za podporo odločanju ali s pomočjo programske opreme za direktorske IS. Izvedba celotnega IS traja običajno nekaj let. Nujna je odločitev, katere projekte razvoja IS realizirati najprej. Prav tako je nujna izdelava prioritetne liste za izvedbo. Zaželeno je, da se najprej realizirajo projekti, ki rešujejo kritične probleme in imajo visoke učinke.

2.2 Proces izdelave strateškega plana Proces izdelave strateškega plana razvoja IS teče preko petih aktivnosti:

Analiza obstoječega stanja. Naloga in poslanstvo obravnavane aktivnosti je analizirati strateške elemente OS, da bo razvit IS v celoti usklajen s smernicami in cilji OS ter podati pregled obstoječega stanja IS.

Opredelitev poslovnih zahtev. Naloga in poslanstvo obravnavane aktivnosti je doseči čim večjo stopnjo razumevanja dogajanja v OS ali delovnem področju. Izdelati je potrebno Pregledni model.

Opredelitev tehnoloških zahtev. Opravila v obravnavani aktivnosti potekajo v smeri določitve tistih potrebnih tehnoloških značilnosti sistema (kritični moduli sistema, uporabniški vmesnik, poročila, distribuiranje podatkov in programov), ki bodo omogočale delovanje IS.

Planiranje informacijskega sistema. Planiranje informacijskega sistema nekega OS so terminsko in po sredstvih opredeljene aktivnosti, ki jih je potrebno izvesti za uresničitev strateškega plana.

Izdelava dokumentacije. Naloga aktivnosti je izdelati dokumentacijo, predvsem slovar izrazov, ki spremlja strateško planiranje.

Znotraj teh aktivnosti se izvedejo določena opravila, katerih rezultat so izdelki strateškega plana. Za izdelavo teh izdelkov potrebujemo enega ali več vhodnih virov:

analiza strateških elementov (poslanstvo, vizija, cilji, usmeritve, problemi, KDU),

pregledni model organizacijskega sistema (organizacijsko shemo, globalni funkcionalni model, globalni model podatkovnih tokov, globalni model delovnih procesov, globalni podatkovni model, model uporabe mobilnih aplikacij in model povezovanja),

analiza obstoječega stanja IS,

analiza vpliva IT,

načrt IT,

plan razvoja IS in

slovar izrazov.

30

Slika 2.2.1: Vhodni dokumenti ali viri in izdelki strateškega plana

31

Slika 2.2.2: Zaporedje opravil strateškega planiranja

2.3 Vloge pri strateškem planiranju Nekatere vloge so vključene v postopek strateškega planiranja od začetka do konca projekta (npr. Uporabnik, Izvajalec), druge pa se občasno vključujejo (npr. Presojevalci). Nekatere vloge so posamične (npr. Uporabnik, Vodja projekta), nekatere pa kolektivne (npr. Projektni svet).

32

3 Predstavitev strukturnega razvoja IS

Že v začetku računalniške dobe je bilo jasno, da brez pravilnega pristopa k obvladovanju in razvoju

sistemov ne bo šlo. Zato se je že v začetku 70ih oblikoval strukturni razvoj – uvedel je disciplinirano

izvajanje analize in načrtovanja. S pomočjo diagramskih tehnik, ki so bile vključene v fazi analize in

načrtovanja, je bilo laže uvajati spremembe, kar je vplivalo na zmanjšanje stroškov vzdrževanja

sistema. Tak pristop je razdelil probleme na manjše lažje obvladljive podprobleme ter uvedel

strogo ločevanje med logičnim in fizičnim načrtovanjem.

Strukturni pristop se je skozi vsa leta izpopolnjeval, nastajale so nove metode in nove tehnike,

dokler se ni v devetdesetih letih pojavil nov pristop, ki je temeljil na objektih in objektnih

metodologijah.

33

3.1 Razvojni modeli Kot večina razvojnih procesov sledi tudi razvoj IS določenemu življenjskemu ciklu, oziroma

razvojnemu modelu, ki določa zaporedje faz razvoja. Razvojni modeli IS zajemajo v grobem

analizo, načrtovanje in izvedbo, med seboj pa se razlikujejo predvsem po podrobnejši delitvi faz na

aktivnosti in v zaporedju ter načinu njihovega izvajanja. Razvojni modeli, ki so značilni za strukturni

razvoj IS, so: zaporedni model, iterativni model in inkrementalni model.

3.1.1 Zaporedni model

(glej drug dokument)

3.1.1 Iterativni model

(glej drug dokument)

3.1.1 Inkrementalni model

(glej drug dokument)

34

3.2 Uporaba, vrednotenje in prilagajanje metodologije Praktično vsak projekt je nekaj posebnega, zato je težko pričakovati, da bo zapisan proces dober za vse primere. Agilna metodologija mora omogočati prilagajanje obsega metodologije, tako da ta kar najbolj ustreza konkretnemu primeru. Poleg tega je potrebno poskrbeti za stalno obnavljanje metodologije, v okviru katerega se zajema in formalizira postopke in druge elemente, ki se skozi uporabo izkažejo kot koristni.

V začetku je potrebno proučiti obstoječo metodologijo. Pri tem sodelujeta metodolog in skrbnik metodologije. Z upoštevanjem načel in priporočil agilnih pristopov metodolog in skrbnik metodologije predlagata prvi osnutek agilne metodologije, ki jo morajo potrditi tudi ostali skrbniki vlog. Za skrbnike vlog so izbrani posamezniki, ki so za določeno področje najbolj izkušeni. Njihova dolžnost je, da v sodelovanju z ostalimi uporabniki, ki nastopajo kot nosilci vloge, stalno dopolnjujejo metodologijo s priporočili in smernicami, ki jih pridobijo z izkušnjami na posameznih projektih. Dopolnjevanje metodologije je tudi dolžnost skrbnika metodologije. Od njega se pričakuje, da stalno spremlja novosti in se udeležuje dogodkov s področja metodologij razvoja programske opreme. Pri uporabi metodologije na konkretnem projektu skrbnik metodologije najprej prouči lastnosti projekta in določi osnovne korake metodologije. Sem sodi določanje opcijskih aktivnosti, določanje potrebnih vlog, izbira izdelkov, izbira življenjskega cikla in podobno. Po zaključku iteracije se na kratko sestanejo skrbnik metodologije in skrbniki vlog ter se pogovorijo o uporabnosti metodologije.

35

Tu navadno ne gre za korenite spremembe metodologije, temveč zgolj za podrobnosti, ki lahko še povečajo učinkovitost metodologije. Pri tem velja poudariti, da spremembe metodologije za potrebe konkretnega projekta ne vplivajo na osnovno metodologijo. Ko je projekt zaključen, skrbnik metodologije organizira sestanek, kjer se skupaj z vsemi sodelujočimi na projektu pogovori o morebitnih spremembah osnovne metodologije.

3.3 Proces strukturnega razvoja Strukturni razvoj IS je obsežen postopek sestavljen iz več aktivnosti. Izvedemo ga v več fazah, v okviru vsake faze je pri določeni aktivnosti potrebno opraviti določena opravila (Slika 3.7). Opravila lahko potekajo vzporedno ali pa zaporedno, odvisno od izdelkov, ki jih vsako od njih potrebuje kot vir, ali v njih nastanejo kot izdelek. Pri strukturnem razvoju poznamo dva splošna pristopa k razvoju: redni in skrajšan. Včasih je zaradi posebnosti problemske domene in okoliščin (časovna stiska, neprimerni ali posebni tehnični pogoji, ipd.) potrebno opravila združevati, jih izvesti manj podrobno ali jih morda celo preskočiti.

Slika 3.3: Shema procesa strukturnega razvoja IS

36

3.4 Vloge pri strukturnem razvoju Pri strukturnem procesu razvoja IS sodeluje veliko ljudi različnih profilov. Za nek tipičen projekt razvoja prikazuje spodnja tabela razdelitev vlog. Glede na obseg in specifike projekta morajo vodstvene strukture predvideti morebitna združevanja ali specializacije vlog. Ena oseba je lahko nosilec več vlog (to posebej velja za manjše projekte), eno vlogo pa lahko opravlja več ljudi (velja za obsežnejše projekte).

37

3.5 Faze strukturnega razvoja

3.5.1 Analiza

Naloga faze analize je izdelati razumljiv opis področja, na katerega se nanaša razvoj aplikativnega sistema. Faza analize daje odgovore na vprašanja tipa KAJ:

katere funkcije in delovne procese mora podpirati aplikativni sistem, kaj se izvaja v elementarnih funkcijah, katera poslovna pravila morajo funkcije upoštevati in katere podatke potrebujejo elementarne funkcije, poslovna pravila in delovni procesi za svoje

delovanje. Osnovna naloga opravil, ki se izvajajo v sklopu faze analize, je izdelava konceptualnih modelov: podatkovnega, funkcionalnega, procesnega in modela poslovnih pravil. V fazi analize so izdelani konceptualni modeli med seboj odvisni. Glavni cilji faze analize so:

izdelati podrobni procesni, funkcionalni in podatkovni model za delovna področja,

izdelati model poslovnih pravil,

definirati podrobne funkcionalne, informacijske in tehnološke zahteve za IS in

opredeliti tehnološko strukturo strojne ter programske opreme, na kateri bo IS deloval.

Kritični dejavniki uspeha faze analize so: izdelan ažuren strateški plan, uporabnik predano sodeluje pri razvoju, razvojna ekipa lahko dobi v ustreznem času vse odgovore,... Aktivnosti v fazi analize so: Opredelitev poslovnih zahtev, opredelitev tehnoloških zahtev, prevedba podatkov, dokumentacija, testiranje in uvajanje.

38

1. Opredelitev poslovnih zahtev Naloga opredelitve poslovnih zahtev je doseči čimvečjo stopnjo razumevanja dogajanja v organizacijskem sistemu oz. procesih ter zajeti poslovna pravila. V tem sklopu je več opravil, katerih izdelki omogočajo popoln pregled nad:

procesi in funkcijami ter načinom izvajanja procesov,

informacijskimi potrebami in načinom povezovanja z informacijskimi sistemi drugih organizacijskih sistemov,

poslovnimi pravili in

potrebnimi podatkovnimi strukturami, ki predstavljajo podatkovno podlago izvajanju procesov.

2. Opredelitev tehnoloških zahtev Naloga je opredeliti potrebne tehnološke zahteve (lastnosti in parametre) sistema, ki bodo omogočale njegovo delovanje v skladu z zahtevami, opredeljenimi v strateškem planu in VDP (vzpostavitveni dokument projekta). To se tiče tako zahtev na področju PO kot tudi HW. Te tehnološke zahteve treba opredeliti že v fazi analize zato, ker nekatere od njih neposredno vplivajo na opravila ali izdelke ostalih aktivnosti v fazi analize. Postavijo se zahteve za tehnološko podporo razvoja in določijo tehnološki parametri – ti bodo omogočili delovanje aplikativnega sistema v skladu s strateškim planom in VDP. 3. Prevedba podatkov Naloga prevedbe podatkov je zasnova in izvedba prevedbe podatkov iz starega aplikativnega sistema v novega. Izvaja se le v primeru prenovitve. Opredeli se strategija prevedbe podatkov. 4. Dokumentacija Naloga je izdelati sistemsko-tehnično in uporabniško dokumentacijo. Dokumentacija sistema je izrednega pomena za njegov nadaljnji razvoj in vzdrževanje. Opredelijo se zahteve in standardi dokumentacije (imeti mora določeno strukturo in vsebino, ter standarde za izgled in prikaz njene vsebine – to naj bi temeljijo na enem izmed standardov za dokumentacije). 5. Testiranje Naloga je zasnovati in izpeljati testiranje aplikativnega sistema. Testiranje je zelo pomembna aktivnost razvoja, saj potrdi pravilnost delovanja aplikativnega sistema. Določi se strategija testiranja. 6. Uvajanje Naloga je uvesti aplikativni sistem v uporabo, kar pomeni naučiti uporabnike uporabljati aplikativni sistem. V sklopu faze analize se v okviru obravnavane aktivnosti določijo zahteve in plan uvajanja.

39

3.5.2 Načrtovanje

Naloga faze načrtovanja je izdelati načrt aplikativnega sistema na podlagi modelov in ostalih specifikacij, ki so bili izdelani v fazi analize. Faza načrtovanja daje odgovore na vprašanja tipa KAKO:

kako mora delovati aplikativni sistem, ki bo ustrezal zahtevam, evidentiranim v fazi analize. Glavni cilji faze načrtovanja so:

izdelati načrt aplikativnega sistema, ki ustreza specifikacijam, ki smo jih pridobili v fazi analize in upošteva tehnološke omejitve sistema,

dokumentirati specifikacije načrta na način, ki bo omogočal vzdrževanje sistema in

zasnovati strategijo prehoda iz obstoječe na novo aplikacijo. Kritični dejavniki uspeha faze načrtovanja so: razvojna ekipa pozna kapacitete strojne opreme, ekipa pozna funkcionalne zahteve, med člani ekipe je vzpostavljena komunikacija. Aktivnosti v fazi načrtovanja so: Opredelitev tehnoloških zahtev, načrtovanje podatkovne baze, načrtovanje in izdelava programskih modulov, prevedba podatkov, dokumentacija, testiranje, uvajanje in uporaba sistema.

40

1. Opredelitev tehnoloških zahtev Ta faza se v analizi še ne konča, zato se tukaj nadaljuje. Določi se uporabniški vmesnik, kritične module aplikacije in module, ki pokrivajo povezovanje z ostalimi IS. 2. Načrtovanje podatkovne baze Naloga te aktivnosti je na podlagi podrobnega podatkovnega modela izdelati logični podatkovni model in izvesti ostale korake, potrebne za vzpostavitev učinkovite fizične podatkovne baze. Določi se tudi sistem privilegijev. 3. Načrtovanje in izdelava programskih modulov Naloga je izdelati načrt in implementirati programske module glede na podane funkcionalne zahteve (v okviru danih tehnoloških zmožnosti in omejitev!), ter zagotoviti dokumentacijo modulov, ki bo omogočala njihovo vzdrževanje. Poleg tega se izdela tudi struktura menijev. 4. Prevedba podatkov Izdela se načrt programskih modulov za prevedbo podatkov (ponavadi se podatki iz starih tabel prepišejo v začasne tabele, nato se odpravijo pomankljivosti v izvornih podatkih, potem se pa na podlagi formul in pravil napolnijo nove tabele). 5. Dokumentacija Izdelajo se vzorci dokumentacije ter pripravita se osnutek uporabniške (struktura uporabniške aplikacije) in sistemsko-tehnične dokumentacije (diagrami, seznami objektov, specifikacije,...). 6. Testiranje Izdela se model testiranja in plan testiranja – (testni scenarij mora zagotoviti pregled nad tem KDO, KDAJ, KJE, KAJ, KAKO in ZAKAJ je testiral). 7. Uvajanje Izdela se osnutek uvajalne dokumentacije (to je podlaga za uvajalne tečaje, na katerih se morajo uporabniki naučiti uporabljati aplikacijo pri svojem delu – ta dokumentacija naj bi bila ločena za različne skupine uporabnikov). 8. Uporaba sistema Ta se začne šele v fazi načrtovanja. Naloga je poskrbeti za namestitev aplikativnega sistema in izvesti vse potrebno za začetek uporabe tega sistema. Določi se strategija prehoda na nov sistem oz. uporabe sistema, ter opredeli način spremljanja in preprečevanja vdorov v sistem.

41

3.5.3 Izvedba

Naloga faze izvedbe je izdelati aplikacijo glede na načrt izdelan v fazi načrtovanja. V tej fazi kreiramo fizično podatkovno bazo, generiramo programske module (če CASE to omogoča), in izvedemo vse potrebne programerske posege na modulih. Glavni cilji faze izvedbe so:

izdelati kakovostno, skozi testiranje preverjeno aplikacijo glede na načrt, ki je bil izdelan v fazi načrtovanja,

v primeru prenovitve izpeljati in preveriti testno prevedbo podatkov in

izdelati dokumentacijo aplikacije. Kritični dejavniki uspeha faze izvedbe so: med fazo izvedbe ne prihaja do sprememb v funkcionalnih zahtevah in strukturi podatkov, aktivnosti testrianja so natančno in dobro izpeljana, ekipa na napake, ki jih odkrije v aktivnosti testiranja, takoj odreagira.

42

1. Opredelitev tehnoloških zahtev Izdela se dokončni dokument o potrebnih tehničnih značilnostih sistema. 2. Načrtovanje podatkovne baze Določijo se parametri fizične podatkovne baze in kreira se fizična podatkovna baza. 3. Načrtovanje in izdelava programskih modulov Pripravi se okolje za razvoj programskih modulov in razvijejo se programski moduli. 4. Prevedba podatkov Razvijejo se programski moduli za prevedbo podatkov in izpelje se testna izvedba podatkov. 5. Dokumentacija Izdelajo se uporabniška in sistemsko-tehnična dokumentacija, ter izdelajo se navodila za skrbništvo aplikacije in datoteke pomoči. 6. Testiranje Izvedejo se testiranja na različnih nivojih in pripravi se testno okolje. 7. Uvajanje Pripravi se podatkovna baza za uvajanje in izdela se uvajalna dokumentacija. 8. Uporaba sistema Izdela se plan za namestitev aplikacije.

43

3.5.4 Vpeljava

Naloga faze vpeljave je vpeljati aplikacijo v uporabo v okolje, za potrebe katerega je bila razvita. Glavni cilji faze vpeljave so:

pripraviti produkcijsko okolje in namestiti aplikacijski sistem,

vpeljati uporabnike v delo z aplikacijo,

vpeljati v delo skrbnike aplikacije,

izvesti potrditveni test aplikacije in

spraviti aplikacijo v produkcijo. Kritični dejavniki uspeha faze vpeljave so: dobava in namestitev potrebne strojne in progrmakse opreme mora biti izvedena pravočasno in uspešno, uporabniki sprejemajo novo aplikacijo in se jo želijo naučiti dobro uporabljati, ter potrdtiveni test je uspešno opravljen.

44

3 Prevedba podatkov Izvede se dokončna prevedba podatkov. 4 Testiranje Pripravi se okolje za potrditveni test in se izpelje potrditveni test. 5 Uvajanje Pripravi se okolje za uvajanje, izvede uvajanje uporabnikov in skrbnikov, ter se pripravi ekipa za potrditveni test. 6 Uporaba sistema Pripravi se okolje za vzdrževanja in produkcijsko okolje, začne se uporabljati novi aplikativni sistem in v primeru prenovitve se odstrani starega.

3.5.5 Vzdrževanje

Naloga vzdrževanja je spremljati delovanje aplikativnega sistema, se odvati na odkrite probleme, izvajati nadgradnje ter planirati dodelave. Glavne naloge faze vzdrževanja so:

izpolnjevanje garancijskih obveznosti,

opazovanje zmogljivosti sistema in izvajanje potrebnih korekcij,

beleženje problemov in njihovo razreševanje ter

planiranje nadgradenj, dodelav in izboljšav aplikativnega sistema. Kritični dejavniki uspeha faze vzdrževanja so: vpeljava ustreznih metod za spremljanje delovanja IS, učinkovito razreševanje problemov, dobro sodelovanje med izvajalci in uporabniki,...

45

1. Opredelitev poslovnih zahtev Tukaj se zbirajo zahteve za dodatne posege (odpravljanje napak, dopolnitv in nadgradnje). 2. Opredelitev tehnoloških zahtev Tukaj se opredelijo potrebe po potrebnih tehnoloških nadgradnjah sistema. Izvedejo se potrebni posegi v tehnološko infrastrukturo. 3. Načrtovanje podatkovne baze Vzdržuje se logični podatkovni model, fizični podatkovni model ter parametri delovajna fizične podatkovne baze. 4. Načrtovanje in izdelava programskih modulov Izvedejo se načrtovani posegi na module, ter opravljajo posodobitve. Odločitve na nivoju posodabljanja sprejme metodolog. 5. Dokumentacija Izvajajo se posegi v uporabniško in sistemsko-tehnično dokumentacijo. 6. Testiranje Opravijo se testiranja na različnih nivojih. Odločitev o načinu in potrebah testiranja določita metodolog in vodja razvojne skupine. 7. Uvajanje Opravi se uvajanje za v okviru faze vzdrževanja opravljene spremembe in dopolnitve aplikativnega sistema. Odločitev o načinu in potrebah uvajanja določita metodolog in vodja razvojne skupine. 8. Uporaba sistema Spremlja se delovanje sistema ter na podlagi tako zbranih podatkov podaja predloge za tehnološke in funkcionalne nadgradnje.

46

4 Predstavitev objektnega razvoja IS

4.1 Uvod Objektni pristop k razvoju IS predstavlja eno izmed treh alternativnih poti. Proces objektnega razvoja IS je sestavljen iz več faz. Znotraj posameznih faz izvajamo aktivnosti, te pa bolj natančno delimo na opravila in korake. Osnovno vodilo objektnega razvoja IS je naravnanost na iterativen in inkrementalen procesni model. Na sliki 3.1, ki prikazuje shemo objektnega razvoja IS, horizontalna smer predstavlja časovno os, kjer si sledijo posamezne faze procesa, na vertikalni osi pa so prikazane aktivnosti. Pomembnost in obseg truda, ki ga namenjamo posamezni aktivnosti glede na fazo razvoja, je prikazana z velikostjo pravokotnika, ki se nahaja na stičišču posamezne faze in aktivnosti. Vidimo lahko, da se v različnih fazah razvoja pomembnost posamezne aktivnosti spreminja, s tem pa se spreminja tudi pomembnost opravil, ki jih posamezna aktivnost pogojuje.

Slika 4.1.: Shema objektnega razvoja IS

47

4.2 Definicije pojmov Eden od temeljev razvoja IS je procesni model, ki določa zaporedje izvajanja aktivnosti. Cilj procesnega modela je zagotoviti izdelavo visoko kakovostnega IS, ki bo zadovoljila potrebe končnega uporabnika v okvirih predvidenega časovnega in finančnega načrta. Procesni modeli so pomembni, ker zagotovijo osnovo za pridobitev odgovorov na pet bistvenih vprašanj:

Planiranje - Kaj bomo naredili, da dosežemo zadane cilje?

Pooblastila - Kako lahko vplivamo na dogajanje z namenom priti tja, kamor smo namenjeni?

Napovedi - Kam bomo prišli oziroma kam gremo?

Ocenitev - Kje v procesu smo in zakaj?

Sledljivost - Kako smo dosegli rezultat - npr. kako je posamezen del kode povezan z modeli v načrtovanju in analizi ter nazaj do zahtev?

Procesni model je torej skupek pravil, strategij, aktivnosti, metod, opravil in korakov, katerih namen je doseči poslovne cilje. Pravila zajemajo mnenja ali prepričanja, ki pa so osnova za izbiro aktivnosti, strategij, metod in opravil. Ena izmed pravil so recimo, da je problem potrebno razumeti, še preden se lotimo njegovega reševanja, identifikacija in upravljanje tveganja je pomemben za upseh, delne predaje povečujejo zaupanje razvijalcev in naročnikov,... Strategija izgradnje IS opisuje in narekuje širši pogled na izvajanje aktivnosti v procesu, ne da bi se obremenjevali s podrobnostmi. Strategije, uporabne pri definiranju procesnega modela organizacije, ki uporablja objektno tehnologijo, so iterativnost, inkrementalnost, prototipiranje in ponovna uporaba. Iteracija je en prehod skozi vse aktivnosti procesa. Vsaka iteracija gre skozi vse vidike razvoja IS – aktivnosti, seveda z različnim poudarkom na posamezni aktivnosti glede na fazo. Aktivnost je skupek opravil, ki jih izvedemo z namenom doseči določen cilj. Te so na primer zajemanje zahtev, analiza, načrtovanje objektov, arhitekture, implementacija, testiranje,...

Metoda je poseben način izvajanja aktivnosti. Na primer strukturna analiza je metoda za izvajanje analize; analiza obnašanja objektov je metoda za izvajanje OO analize,... Opravilo je poseben način uporabe metode v sklopu dane aktivnosti. Opis opravila vsebuje opravilu primerne informacije, kot so potrebni viri pred pričetkom in aktivnost procesnega modela kateri pripadajo. Opravilo lahko nadalje delimo na korake. Korak predstavlja nadaljnjo delitev opravil. Podobno kot opravilo, tudi korak okarakterizira informacije o zahtevanih vhodih, potrebnih virih in izdelkih.

48

4.3 Pomembne strategije objektnega razvoja Pri objektnem pristopu so pomembne sledeče strategije:

iterativni razvoj,

inkrementalni razvoj,

prototipiranje in

ponovna uporaba. (glej drug dokument)

4.4 Proces objektnega razvoja Proces razvoja IS je razdeljen na posamezne faze. Pri objektnem razvoju ločimo štiri osnovne faze in sicer začetna faza, faza zbiranja zahtev, faza konstrukcije ter faza prevzema. Faze prikazujejo časovno delitev objektnega procesa. Iterativno inkrementalna narava objektnega pristopa narekuje predstavitev procesnega modela v dveh dimenzijah:

po času – predstavlja življenjski cikel procesa in

po aktivnostih – predstavlja sestavne dele procesa. Tovrstna predstavitev v procesnem modelu poveže dva do sedaj ločena pogleda na razvoj IS. Gledano iz časovne perspektive govorimo o fazah, katere delimo na razvojne cikle - iteracije in mejnike. Tak pogled je značilen za upravljavski nivo gledanja na projekt (projektno vodenje). Le ta zajema časovno komponento, sredstva, ljudi in organizacijo dela. Gledano iz perspektive proizvodov pa razvojni proces delimo na posamezne aktivnosti. Pri tem ločimo tehnične aktivnosti (kar ta predmet zavzema) in podporne aktivnosti (upravljanje konfiguracij in sprememb, vodenje projektov, uporaba metrik, upravljanje okolja, kar ta predmet ne zavzema). Iz opisa procesa objektnega razvoja IS so izvzete tudi aktivnosti, ki se z objektnim pristopom ne spremenijo, npr. načrtovanje grafičnega uporabniškega vmesnika, razvoj podatkovne baze, oblikovanje uporabniške dokumentacije, oblikovanje tehnične dokumentacije.

Slika 4.4: Tehnične aktivnosti v procesu objektenga razvoja IS

49

4.4.1 Dinamični vidik

Začetna faza - projekt definiramo s poslovnega stališča in določimo njegov obseg. V ta namen poiščemo vse zunanje entitete, s katerimi bo sistem sodeloval (ter na grobo kako). Poiskati moramo vse primere uporabe (opišemo le najpomembnejše). Določimo kriterije uspeha oziroma neuspeha projekta, ocenitev tveganj, presojo potrebnih virov in fazni načrt, iz katerega so razvidni glavni časovni mejniki. Faza zbiranja informacij - analiziramo problemsko področje, postavimo osnovno ogrodje arhitekture sistema, izdelamo projektni plan in razrešimo najbolj tvegane elemente projekta. Prototipno realiziramo sistem do te mere, da lahko prikažemo glavne primere uporabe. Na koncu te faze pregledamo podrobne cilje sistema in njegov obseg, izbiro arhitekture in morebitna tveganja. Faza konstrukcije - z iterativno inkrementalnim postopkom izdelamo celoten proizvod, ki je pripravljen za prenos k uporabniku. Faza konstrukcije zajema opis preostalih primerov uporabe, načrtovanje, zaključek implementacije in testiranje. Faza prevzema - osnovni cilj te faze je predaja izdelka v uporabnikovo okolje. S tem se pogosto pojavi potreba po dodatnih popravkih. Tipično ta faza nastopi z beta verzijo proizvoda.

50

3.4.4 Statični vidik

Proces objektnega razvoja IS lahko opazujemo tudi s stališča aktivnosti, ki jih izvajamo. Tukaj si bomo ogledali torej samo prvo skupino aktivnosti – tistih, ki so tehnične narave. Aktivnost Zajemanje zahtev

51

Aktivnost Analiza

Aktivnost Arhitekturno načrtovanje

52

Aktivnost Načrtovanje objektov

Aktivnost Implementacija

53

Aktivnost Testiranje

54

4.4.3 Vloge pri objektnem razvoju

Tabela podaja seznam nekaterih najpomembnejših vlog, ki se pojavijo v času projekta skozi vse štiri razvojne faze in kratek opis njihovih odgovornosti. Poleg teh vlog se v procesu objektnega razvoja pojavljajo tudi druge vloge, ki pa imajo enak pomen kot pri ostalih pristopih razvoja in so zato izpuščeni iz opisa. Pri tem mora biti jasno, da vloga ne predstavlja dejanske osebe, ampak pomen, ki jo oseba v nekem trenutku (in na določenem delovnem mestu) ima za razvojni projekt. Tako lahko ena oseba predstavlja več vlog ali pa obstaja več oseb, ki predstavlja eno samo vlogo v projektu.

hčklč

Slika 4.1.6.2: Zaporedje opravil strateškega planiranja

55

5 Predstavitev razvoja IS za upravljanje delovnih

procesov

Razvoj IS za upravljanje delovnih procesov (v nadaljevanju SUDP) predstavlja tretji možen pristop k razvoju po strateškem planiranju. Pri SUDP prihaja do prepletanja različnih sodobnih informacijskih tehnik ter organizacijskih dejavnikov. Osnovni cilji razvoja SUDP so poenostavitev delovnih procesov, skrajšanje časa izvajanja procesa na eno zahtevo, zmanjšanje stroškov uvajanja in izvajanja delovnih procesov s poudarkom na stroških njihovega vzdrževanja ter zadostitev potreb uporabnikov z doseganjem ustreznega nivoja kakovosti delovnih procesov.

5.1 Definicije pojmov Delovni proces predstavlja množico povezanih aktivnosti, katerih izvedba pomeni dodano vrednost pri uresničevanju skupnega cilja organizacijskega sistema. Aktivnosti delovnega procesa so lahko informacijsko podprte, avtomatizirane, lahko pa se izvajajo povsem ročno. SUDP je sistem, kjer so definirani, krmiljeni, izvajani in nadzorovani delovni procesi ali deli delovnih procesov z uporabo informacijske tehnologije, pri čemer so ključnega pomena uporabniki. SUDP predstavlja sistem za podporo štirim funkcijam:

funkcija izgradnje sistema (definiranje in modeliranje delovnih procesov),

funkcija izvajanja delovnih procesov (poganjanje primerkov delovnih procesov v realnem okolju),

funkcija razporejanja nalog in sistemskih vmesnikov (razporejanje nalog med uporabnike sistema ali udeležence delovnih procesov) ter

funkcija interakcije v času izvajanja (za povezavo končnih uporabnikov SUDP in informacijske tehnologije pri izvedbi posameznih korakov ali aktivnosti delovnega procesa).

Aktivnost je najmanjša enota delovnega procesa, ki jo je potrebno določiti pri definiciji delovnega procesa. Njeno izvajanje v okviru SUDP lahko poteka v sodelovanju z uporabnikom ali popolnoma avtomatsko. Definicija delovnega procesa pomeni formalen zapis delovnega procesa v računalniškem jeziku, ki vsebuje osnovne podatke o procesu in podatke, potrebne za razvoj SUDP. Orodja za upravljanje delovnih procesov (v nadaljevanju OUDP) so orodja, ki omogočajo definiranje delovnih procesov, izvajanje delovnih procesov ter nadzor nad izvajanjem delovnih procesov in skrbništvo nad delovanjem celotnega SUDP. Modeliranje delovnih procesov je postopek, pri katerem se ugotavlja zaporedje izvajanja aktivnosti delovnega procesa in se uporablja eno izmed diagramskih tehnik za prikaz povezovanja teh aktivnosti z uporabniki, pravili, aplikacijami, podatki, dokumenti in ostalimi elementi, ki so del delovnega procesa. Optimizacija delovnih procesov pomeni odpravljanje slabosti delovnega procesa z uvedbo novih tehnoloških rešitev za obstoječi delovni proces, pri čemer se organizacijski sistem, ki delovne procese izvaja, bistveno ne spremeni.

Prenovitev delovnih procesov pomeni ponovno definiranje celotnega delovnega procesa. Vključujejo tudi organizacijske spremembe. S prenovitvijo skušamo zagotoviti izboljšave delovnih procesov, ter vplivati na stroške, kakovost izdelkov, hitrost izvajanja delovnih procesov,...

56

5.2 Shema razvoja SUDP Slika prikazuje shemo razvoja SUDP. X-os predstavlja zaporedje faz procesa razvoja, na y-osi pa so prikazane aktivnosti, ki vključujejo izvajanje enega ali več opravil. Obseg dela, ki ga namenjamo posamezni aktivnosti, je prikazan z velikostjo pravokotnika, ki ponazarja posamezno opravilo. Vidimo lahko, da se v različnih fazah razvoja obseg posamezne aktivnosti spreminja.

5.3 Proces razvoja SUDP Razvoj SUDP je razdeljen v dva sklopa. Prvi sklop sestavljata dve fazi izgradnje SUDP, to sta analiza in modeliranje ter namestitev sistema, drugi sklop pa sestavljata dva vidika upravljanja SUDP, in sicer izvajanje delovnih procesov ter nadzor nad izvajanjem. Obe fazi izgradnje in oba vidika upravljanja sta razdeljena na več aktivnosti, posamezna aktivnost pa vsebuje opravila, ki predstavljajo vsebinsko zaokroženo področje.

57

5.4 Vloge pri razvoju SUDP Glede na navedeno razdelitev vlog se je potrebno zavedati dejstva, da je lahko ena oseba nosilec več vlog, prav tako pa lahko naloge iste vloge opravlja tudi več oseb.

5.5 Faze procesa razvoja SUDP

5.5.1 Analiza in modeliranje

Prva faza izgradnje SUDP je namenjena zbiranju podrobnih funkcionalnih, informacijskih in tehnoloških zahtev glede delovnih procesov, izdelavi procesnih modelov ter opredelitvi strojne in programske opreme, na kateri bo SUDP deloval. V tej fazi se pri analizi odkrijejo ključni ter tudi neučinkoviti delovni procesi, ki so kritični za fazo namestitve sistema.

58

Spodnja slika prikazuje vhodne izdelke in pomembnejše rezultate faze analize in modeliranja.

Analiza delovnih procesov

Analizo izvedemo tako, da procese identificiramo, jih poimenujemo in opišemo, pri čemer morajo nujno sodelovati tisti v organizacijskem sistemu, ki delovne procese dobro poznajo. Pri določitvi neučinkovitih delovnih procesov opredelimo tiste delovne procese, ki povzročajo prevelike stroške, ne dajejo pravih rezultatov ali pa so v nasprotju s pričakovanji izvajalcev delovnega procesa, vodstva ali strank. Pri določitvi ključnih delovnih procesov določimo tiste delovne procese, s katerimi se uresničujejo cilji in usmeritve organizacijskega sistema, ki so določeni v strategiji organizacijskega sistema. Analiza in namestitev programske opreme Pri tej aktivnosti v okviru faze analize in modeliranja najprej med seboj primerjamo tehnologije OUDP glede na potrebe organizacijskega sistema. Zatem se odločimo, izberemo in namestimo najbolj ustrezno izmed možnih tehnologij OUDP, nato pa izvedemo še analizo potreb po uporabniških aplikacijah ter analizo potreb po podpornih aplikacijah. Definiranje in izvajanje delovnih procesov Pri tej aktivnosti v okviru faze analize in modeliranja se izdela analiza aktivnosti delovnih procesov, z diagramskimi tehnikami se izdelajo modeli delovnih procesov, izdelajo se uporabniški vmesniki, simulira se izvajanje delovnih procesov ter izvaja se prenovitev oz. optimizacija delovnih procesov.

59

5.5.2 Namestitev sistema

Druga faza izgradnje SUDP je namenjena namestitvi sistema glede na specifikacije, ki so bile zbrane v fazi analize, ter prenosu vseh izdelkov iz razvojnega okolja razvijalcev SUDP v realno okolje. V tej fazi se namestijo vsa potrebna orodja in podporne aplikacije, upoštevajo se tehnološke omejitve sistema, nastavijo se vsi potrebni parametri za nemoteno delovanje sistema, delovanje sistema se preveri na testnih primerih in uporabnike se seznani s splošnimi lastnostmi sistema.

60

Slika prikazuje pomembnejše vhodne izdelke in pomembnejše rezultate faze namestitve sistema.

Analiza in namestitev programske opreme

Pri tej aktivnosti v okviru faze namestitve sistema je potrebno najprej na strežnik namestiti orodje za modeliranje, nato na strežnik namestimo jedro SUDP, zatem na strežnik namestimo nadzorna in skrbniška orodja, sledi namestitev podpornih in uporabniških aplikacij ter uporabniškega vmesnika, nazadnje pa definiramo povezave med jedrom SUDP in ostalo programsko opremo. Definiranje in izvajanje delovnih procesov

Pri tej aktivnosti v okviru faze namestitve sistema se vzpostavi testno okolje za izvajanje delovnih procesov. Pred izvedbo testiranja je potrebno namestiti definicije delovnih procesov in podatkovne strukture ter nastaviti parametre SUDP, s testnim zaganjanjem stroja SUDP pa se lahko odkrijejo še zadnje napake, ki so lahko posledica pomanjkljivega načrtovanja SUDP, velike kompleksnosti SUDP, skritih neskladij med komponentami SUDP ali drugih dejavnikov. Uvajanje sistema in sodelovanje uporabnikov Pri tej aktivnosti v okviru faze namestitve sistema se vse bodoče uporabnike s pomočjo tečaja najprej seznani s splošnimi lastnostmi oz. prednostmi SUDP, nato pa se uporabnike uvede v sistem s pomočjo testnih primerov.

61

5.5.3 Izvajanje delovnih procesov

Prvi vidik upravljanja SUDP je namenjen izvajanju aktivnosti znotraj podprtih delovnih procesov, ki so bili definirani v fazi analize in omogočeni z namestitvijo sistema. Pri tem vidiku se omogoči izvajanje preverjenih delovnih procesov, v izvajanje delovnih procesov se vključi uporabnike in zagotovi se izvajanje potrebnih podpornih aktivnosti.

Definiranje in izvajanje delovnih procesov

Pri tej aktivnosti se izvaja posamezne primerke delovnih procesov. To se izvede s pomočjo stroja SUDP, ki potrebne podatke črpa in shranjuje v podatkovno zbirko. Pri izvajanju delovnih procesov sodelujejo uporabniki in podporne aplikacije, ki so potrebne za izvedbo nekaterih nalog.

Uvajanje sistema in sodelovanje uporabnikov

Pri tej aktivnosti gre predvsem za sodelovanje uporabnikov z uporabniškimi vmesniki ter za sodelovanje med samimi uporabniki.

Izvajanje podpornih aktivnosti Pri tej aktivnosti se izvedejo opravila, ki jih izvajajo podporne aplikacije. Primer takšne aktivnosti je npr. zapisovanje nadzornih podatkov izvajanja delovnih procesov v podatkovno bazo.

62

5.5.4 Nadzor nad izvajanjem

Drugi vidik upravljanja SUDP je namenjen zagotovitvi nadzora nad izvajanjem delovnih procesov. Pri tem vidiku je potrebno poskrbeti za brezhiben potek izvajanja delovnih procesov, ob ugotovitvi nepravočasnosti ali neuspešnosti izvajanja delovnih procesov pa se izvedejo ustrezni ukrepi.

Definiranje in izvajanje delovnih procesov

Pri tej aktivnosti se preverja pravilnost izvajanja posameznih delovnih procesov. Pravilnost izvajanja delovnih procesov se preverja iz vsebinskega ter iz tehničnega vidika, pri čemer se samo izvajanje delovnih procesov loči na posamezna opravila, kot so zaganjanje, ustavljanje, prekinjanje in nadaljevanje izvajanja delovnih procesov.

Analiza delovanja v realnem okolju

Pri tej aktivnosti se na podlagi dejanskega obnašanja SUDP v okolju izdelajo statistične meritve in poročila. Statistični podatki predstavljajo podlago za spreminjanje in izboljšavo delovnih procesov, po potrebi pa se lahko dodaja nove delovne procese ali pa ukinja nepotrebne. Opravila analize delovanja v realnem okolju se lahko izvajajo redno ali izredno na zahtevo.