Fakulteta za elektrotehniko, računalništvo in informatiko

Smetanova ulica 17 2000 Maribor, Slovenija

Borut Klobasa

PRIMERJAVA PROCESNIH OGRODIJ RUP IN MSF

Diplomsko delo

Maribor, december 2013

i

PRIMERJAVA PROCESNIH OGRODIJ RUP IN MSF

Diplomsko delo

Študent: Borut Klobasa

Študijski program: Univerzitetni študijski program

Računalništvo in informatika

Smer: Informatika

Mentor: red. prof. dr. Marjan Heričko

Lektorica: mag. Vesna Gros

ii

iii

Primerjava procesnih ogrodij

RUP in MSF

Ključne besede: Ogrodje RUP, ogrodje MSF, procesno inženirstvo, Združeni

zrelostno zmožnostni model

UDK: 659.2:004(043.2)

Povzetek

Razvoj informacijskih rešitev znotraj predvidenega plana, stroškov in urnika zahteva

urejen pristop. V ta namen IT-industrija uporablja procese razvoja, ki se nahajajo na

različnih nivojih zrelosti. Med njimi so tudi takšni, ki so rezultat procesa prilagoditve

standardnih razvojnih metodologij – procesnih ogrodij. Dve izmed njih, ogrodji RUP in

MSF, sistematično opišemo ter ju primerjamo.

iv

A comparison of RUP and MSF

process frameworks

Key words: RUP framework, MSF framework, process engineering, Capability

Maturity Model Integration

UDK: 659.2:004(043.2)

Abstract

Development of IT solutions within the expected plan, cost and schedule requires a

systematic approach. For this purpose the IT industry uses software processes on

different levels of maturity. Among them are also processes obtained from the adaptation

of standard development methodologies – process frameworks. In this thesis RUP and

MSF process frameworks are systematically described and compared.

v

ZAHVALA

Iskrena hvala red. prof. dr. Marjanu Heričku.

Iskrena hvala izr. prof. dr. Jožefu Ritonji. Iskrena hvala Jelki in sestri Bronji.

vi

KAZALO

1 UVOD ........................................................................................................................................ 1

2 POMEN PROCESA RAZVOJA INFORMACIJSKIH REŠITEV ........................................ 3

3 OCENITEV ZRELOSTI PROCESA RAZVOJA INFORMACIJSKIH REŠITEV .............. 7

4 PROCESNA OGRODJA ZA RAZVOJ INFORMACIJSKIH REŠITEV ........................... 13

5 OGRODJE RUP..................................................................................................................... 17

5.1 Zgodovina .................................................................................................................................... 18

5.2 Struktura ogrodja RUP.................................................................................................................. 20

5.2.1 Osnovni elementi vsebine ......................................................................................................... 22

5.2.2 Napotki ...................................................................................................................................... 24

5.2.3 Osnovni elementi procesa ......................................................................................................... 25

5.3 Značilnosti ogrodja RUP ............................................................................................................... 26

5.3.1 Najboljše prakse ........................................................................................................................ 26

5.4 Faze ogrodja RUP ......................................................................................................................... 29

5.5 Discipline ogrodja RUP ................................................................................................................. 32

6 OGRODJE MSF ..................................................................................................................... 41

6.1 Zgodovina .................................................................................................................................... 42

6.2 Struktura ogrodja MSF ................................................................................................................. 44

6.3 Značilnosti ogrodja MSF ............................................................................................................... 44

vii

6.4 Vloge ogrodja MSF ....................................................................................................................... 47

6.5 Poti ogrodja MSF .......................................................................................................................... 51

6.6 Discipline ogrodja MSF ................................................................................................................. 55

7 PRIMERJAVA OGRODIJ RUP IN MSF ............................................................................ 58

7.1 Značilnosti .................................................................................................................................... 58

7.2 Discipline ...................................................................................................................................... 63

7.3 Faze in poti ................................................................................................................................... 64

7.4 Vloge ............................................................................................................................................ 65

7.5 Izdelki ........................................................................................................................................... 66

7.6 Pristopi k prilagoditvi in inačice .................................................................................................... 67

7.7 Dopolnilna ogrodja ali procesi ...................................................................................................... 68

7.8 Podpora orodij ............................................................................................................................. 68

8 ZAKLJUČEK .......................................................................................................................... 70

VIRI ................................................................................................................................................ 72

viii

KAZALO SLIK

SLIKA 1: SCENARIJI PRILAGAJANJA PROCESNEGA OGRODJA ........................................ 15

SLIKA 2: EVOLUCIJA RUP ........................................................................................ 18

SLIKA 3: ORODJE RMC IN BAZA ZNANJA RUP ........................................................... 19

SLIKA 4: OGRODJE RUP ......................................................................................... 20

SLIKA 5: ITERACIJE – PRIREJENO PO ......................................................................... 21

SLIKA 6: OSNOVNI ELEMENTI OGRODJA RUP ............................................................ 22

SLIKA 7: KONCEPTUALNI MODEL KLJUČNIH KONCEPTOV .............................................. 23

SLIKA 8: ŽIVLJENJSKI CIKEL TEHNOLOŠKIH REŠITEV PODJETJA MICROSOFT .................. 41

SLIKA 9: EVOLUCIJA OGRODJA MSF ......................................................................... 42

SLIKA 10: MSF FOR AGILE SOFTWARE DEVELOPMENT .............................................. 43

SLIKA 11: MSF DRUŽINSKO DREVO .......................................................................... 43

SLIKA 12: MSF MODEL SKUPINE ............................................................................... 48

SLIKA 13: MODEL OBVLADOVANJA ............................................................................ 52

SLIKA 14: IZDAJE OZNAČENE Z VERZIJO .................................................................... 64

ix

KAZALO TABEL

TABELA 1: NIVOJI NADALJEVALNE IN STOPENJSKE PREDSTAVITVE MODELA CMMI .......... 8

TABELA 2: ATRIBUTI PROCESNIH OGRODIJ ................................................................. 14

TABELA 3: NAPOTKI OGRODJA RUP ......................................................................... 25

TABELA 4: GLAVNE IN OBROBNE VLOGE TER IZDELKI DISCIPLIN OGRODJA RUP ............. 39

TABELA 5: CILJI KAKOVOSTI .................................................................................... 49

TABELA 6: GLAVNI IZDELKI POTI IZGRADNJE – KLASIFICIRANI PO VLOGAH ..................... 53

TABELA 7: PRIMERJAVA DISCIPLIN OGRODJA RUP Z DISCIPLINAMI IN VLOGAMI

OGRODJA MSF ....................................................................................... 63

TABELA 8: ŠTEVILO VLOG OGRODIJ RUP IN MSF ...................................................... 65

TABELA 9: KONCEPTUALNA PRESLIKAVA VLOGE PRODUKTNI VODJA V VLOGE

OGRODJA RUP ...................................................................................... 66

TABELA 10: INAČICE OGRODIJ RUP IN MSF .............................................................. 67

TABELA 11: PODPORNA ORODJA OGRODIJ RUP IN MSF ............................................ 69

x

UPORABLJENE KRATICE

CASE Computer Aided Software Engineering

CMMI Capability Maturity Model Integration

EPF Eclipse Process Framework

HTML Hyper Text Merkup Language

IT Information Technology

JAD Joint Application Development

IS Information System

RMC Rational Method Composer

MOF Microsoft Operation Framework

MSF Microsoft Solution Framework

SOA Service Oriented Architecture

SOMA Service Oriented Modeling and Architecture

SPEM Software Process Engineering Metamodel

SPICE Software Process Improvement and Capability Determination

UMA Unified Method Architecture

1

1 UVOD

Številna IT-podjetja/organizacije še vedno razvijajo programsko opremo na osnovi

metodologij, ki niso formalno opredeljene, torej metodologij, ki niso dokumentirane [18].

Te neformalne metodologije so precej stihijske in njihova izvedba je prepuščena

izvajalcem, ki ne uporabljajo sistematičnega procesa razvoja oz. formalnih metodologij.

Proces razvoja (angl. software process, software development process) je dogovorjen

postopek izdelave programske opreme, ki običajno zajema zbiranje zahtev, analizo,

načrtovanje, kodiranje, testiranje, predajo, vzdrževanje in opustitev [21]. Koncept procesa

razvoja lahko v splošnem razumemo tudi kot zaporedje aktivnosti, ki se morajo izvršiti z

namenom izdelave programskega sistema [20]. V opisanem primeru podjetja/organizacije

sledijo nekemu neformalnemu oziroma "ad hoc" procesu razvoja, ki se večinoma nahaja v

obliki skritega oziroma neformaliziranega znanja v glavah razvijalcev in bi ga glede na

model CMMI (Združeni zrelostno zmožnostni model) opredelili kot začetni oz. nepopolni

proces. Več o tem modelu v tretjem poglavju. Uvedba dobro definiranega in

dokumentiranega procesa bi za te poslovne subjekte med drugim pomenila lažje uvajanje

novih članov, lažje pridobivanje naročnikov ter možnost izdelave standardne

dokumentacije [18]. Uporaba predpisanega procesa razvoja pri srednje do zelo velikih

projektih poveča verjetnost uspešnosti projekta [2]. To pa ni tako izrazito pri majhnih

projektih z manj člani, kjer so sposobnosti članov razvojne skupine in dobra razvojna

orodja pomembnejša od uporabljenega procesa [2, 20]. Tam se lahko uporabljajo manj

formalne (agilne) oblike pristopov h gradnji informacijskih rešitev. Agilne metodologije

manj formalno opišejo proces razvoja in poudarjajo pomen posameznikov in

komunikacije, delujoče programske opreme, sodelovanja uporabnika in reagiranja na

spremembe [18]. Pomen procesa razvoja oziroma sistematičnega pristopa je opisan v

drugem poglavju.

IT-podjetja/organizacije lahko oblikujejo in zapišejo svoje procese, izhajajoč iz lastnih

izkušenj in znanj, pridobljenih z izvajanjem avtomatiziranih in neavtomatiziranih aktivnosti

na podlagi postopkov, smernic, napotkov, standardov, načel itn. bolj ali manj formalno v

priročnike oz. standardne postopke. Ključnega pomena za uporabnost metodologije je

njena zmožnost, da se prilagaja posameznim projektom. Vsak projekt je namreč nekaj

2

posebnega, zato je težko pričakovati, da bo zapisan proces razvoja učinkovit v vseh

primerih. Ta način lahko imenujemo strategija od spodaj navzgor (angl bottom-up).

Alternativni način je uporaba metodologij, npr. XP, Scrum, in generičnih metodologij oz.

procesnih ogrodij, ki pa jih je potrebno prilagoditi posameznim razvojnim projektom, kar je

opisano v četrtem poglavju, kjer je podana tudi tabela z atributi nekaterih standardnih

procesnih ogrodij. To strategijo lahko imenujemo od zgoraj navzdol (angl. top-down).

Osnovni cilj diplomske naloge je spoznati pomen različnih procesnih modelov in

sistematično opisati ter primerjati procesni ogrodji RUP (Rational Unified Process) in MSF

(Microsoft Solution Framework). Temu so namenjena četrto, peto, šesto in sedmo

poglavje. Slednje poda kriterije (točke) primerjave obeh ogrodij. Primerjali smo značilnosti,

discipline, faze in poti, vloge, izdelke, pristope k prilagoditvi in inačice, dopolnilna ogrodja

ali procese ter podporna orodja.

3

2 POMEN PROCESA RAZVOJA INFORMACIJSKIH REŠITEV

V vsaki organizaciji, ki razvija informacijske rešitve, je prisotna neka metodologija.

Metodologijo lahko opredelimo kot množico dogovorov (konvencij), s katerimi se člani

projektne skupine/organizacije strinjajo [18]. Razdeljena je na formalni del oz. proces

razvoja in neformalni del, ki temelji na izkušnjah in skritem znanju ter je prežet s filozofijo,

načeli, idejami in pogledi organizacije ter njenih članov, kar še posebej poudarja njeno

sociološko komponento. Metodologija je torej več kot le skupek metod in tehnik [18].

Proces razvoja programske opreme je definiran s štirimi vidiki [16]. Kdo (vloge, prvi vidik)

je odgovoren za kaj (izdelki, drugi vidik), kako (opravila in aktivnosti oz. metode, tretji

vidik) in kdaj (delovni tokovi oz. podprocesi, življenjski cikli oz. procesi, četrti vidik). Izdelki

so običajno povezani s predlogami, primeri in opisi orodij, ki se uporabljajo pri njihovi

izdelavi, vloge pa so lahko dodatno opisane s potrebnim ali priporočenim znanjem. Proces

razvoja tako s specificiranjem kdo, kaj, kako in kdaj preslika vhodne uporabniške zahteve

v delujoč programski oz. informacijski sistem. Razvoj izdelkov je povezan z vlogami, ki

opravljajo določena opravila v sklopu aktivnosti in pri svojem delu uporabljajo različne

tehnike. Teh je več vrst. Poznamo procesne tehnike (diagrami podatkovnih tokov,

odločitvena drevesa in akcijski diagrami), strukturne tehnike (strukturni diagrami),

podatkovne tehnike (tehnike podatkovnega modeliranja), tehnike dela z ljudmi (JAD –

Joint Application Development itd.) in objektne tehnike, kot so diagramske tehnike jezika

UML (Unified modeling Language), tehnike identifikacije razredov in funkcionalnosti itd.

[18].

Skupna značilnost mnogih različnih definicij procesa, ki jih najdemo v literaturi, je

zaporedje faz in mejnikov, ki izražajo življenjski cikel izdelka v razvoju. Procesi tudi

definirajo pot od enega mejnika do drugega z opredelitvijo sosledja dela, operacij ali

dogodkov, ki zahtevajo čas, znanje ali druge vire in proizvajajo izdelke [1]. Štiri temeljne

aktivnosti, ki so osnova vsakega procesa razvoja, so specifikacija, razvoj, validacija in

evolucija programske opreme [20].

4

Proces razvoja vsem udeležencem v projektu razvoja programske opreme omogoča, da

učinkovito in uspešno sodelujejo, se učijo in izmenjujejo različne informacije in znanja ter

si delijo skupno vizijo razvoja. Proces razvoja predstavlja temelj za spremembe

(izboljšave) v razvoju programske opreme. Vzroke za prekoračitev proračunov, zamude in

pomanjkljivosti v projektih izgradnje informacijskih rešitev lahko pogosto pripišemo

procesu razvoja. V teh primerih standardni procesi bodisi niso implementirani, so zastareli

ali pa niso enostavno dostopni. Brez njih pa razvoj in upravljanje postaneta "ad hoc".

Produktivnost upade, ker člani razvojne skupine ne vedo, kaj naj naredijo. In ko se selijo iz

projekta na projekt, se morajo vse naučiti znova. Zastareli in nedostopni procesi niso

koristni. Metodologije razvoja morajo zato podpirati sodobne poti razvoja informacijskih

rešitev (npr. SOA) in to na način, ki zagotavlja visoko produktivnost in učinkovitost.

Za projekte, ki ne uporabljajo procesa razvoja, je značilno, da ne delujejo učinkovito, ker

temeljijo predvsem na skritem znanju ter izkušnjah posameznikov. Učinkovitost upade,

ker člani projekta sicer ustaljene najboljše prakse velikokrat pozabijo uporabiti ter zaradi

povečanega obsega komuniciranja, ki je posledica neopisanih vlog. Po drugi stani pa več

procesa lahko povzroči manjšo kreativnost in produktivnost, ker je potrebno v projektih

opravljati naloge in izdelovati izdelke, ki dodajo končnemu rezultatu kvečjemu le majhno

ali pa celo nič vrednosti. Najbolj učinkovito je, da se proces prilagodi potrebam projekta.

Za manjše projekte, kjer so skupine locirane skupaj, so procesi lahko preprosti in manj

formalni. Za velike, porazdeljene projekte, ki uporabljajo različne tehnologije in morajo biti

skladni s strogimi standardi, postanejo procesi bolj kompleksni in disciplinirani. Poleg tega

faza življenjskega cikla projekta vpliva na proces razvoja. Tako se npr. v začetni fazi

tipično pojavlja veliko nedorečenosti kot tudi kreativnosti v naslavljanju poslovnih potreb,

kar pomeni manjšo definiranost procesa.

Skupen proces razvoja v in med razvojnimi skupinami ponuja veliko prednosti [3]:

● vsi člani razvojne skupine razumejo, kaj je potrebno storiti, da bi lahko razvili

programski produkt,

● razvijalci bolje razumejo, kaj počnejo drugi razvijalci – v prejšnjih ali kasnejših fazah

istega projekta, v podobnih projektih v istem podjetju, na različnih geografskih

lokacijah in tudi v projektih v drugih organizacijah,

● nadzorniki in menedžerji, tudi tisti, ki ne znajo brati kode, lahko s pomočjo arhitekturnih

risb razumejo, kaj počnejo razvijalci,

5

● razvijalci, nadzorniki in menedžerji lahko prehajajo med projekti ali med oddelki, ne da

bi se morali naučiti novega procesa,

● znotraj podjetja je usposabljanje standardizirano in

● potek razvoja programske opreme je ponovljiv, kar pomeni, da lažje planiramo

projektna opravila in ocenimo stroške dovolj natančno, da izpolnimo pričakovanja.

Procese razvoja uporabljamo tudi zato, ker želimo preprečiti [10],

● da bi bil rezultat projekta napačen produkt,

● da bi bila kakovost produkta slabša od pričakovane,

● da bi projekt trajal dalj časa od predvidenega,

● da bi projektno osebje delalo po 80 in več ur tedensko in

● da ne bi izpolnili danih zavez.

Temeljne aktivnosti se izvajajo tudi v razvojnih okoljih, ki ne uporabljajo formalnega

procesa razvoja, ki smo ga opisovali do sedaj in zato programske rešitve večinoma

razvijajo nesistematično. Za te "ad hoc" procese razvoja so značilni [13]:

● projekti, ki se izvedejo izven planiranih časovnih okvirov,

● prekoračitev stroškov,

● ni mehanizmov, ki bi to preprečevali,

● uspešni projekti so sicer možni, vendar

● so odvisni od sposobnosti in nadpovprečnih naporov razvijalcev,

● niso rezultat ponovne uporabe preizkušenih metod, ki so značilne za zrelo

organizacijo,

● ponovitev rezultatov na naslednjem projektu je odvisna od razpoložljivosti

istih posameznikov. Več o "ad hoc" procesih razvoja v naslednjem poglavju.

Medtem ko veljajo za nezrelo organizacijo, ki razvija informacijske rešitve in programsko

opremo, naslednje značilnosti [13]:

● proces razvoja je improviziran,

● tudi če je zapisan, opredeljen, se ga uporabniki ne držijo,

● menedžerji se ukvarjajo predvsem s kriznimi situacijami,

● roki za dokončanje in sredstva za realizacijo so običajno prekoračeni in

6

● če so roki za dokončanje doseženi, trpi kakovost in funkcionalnost izdelkov,

pa veljajo za zrelo organizacijo, ki razvija informacijske rešitve in programsko opremo,

naslednje značilnosti:

● delo poteka v skladu z definiranim softverskim procesom razvoja,

● vsi delavci so seznanjeni s softverskim procesom (izobraževanje),

● proces razvoja je dokumentiran in se po potrebi dopolnjuje,

● zahtevani postopki so neposredno uporabni in so konsistentni z dejanskim potekom

dela,

● izboljšave temeljijo na rezultatih pilotskih preizkusov ter analiz stroškov in koristi in

● vloge in odgovornosti znotraj procesa so jasne tako na nivoju projekta kot v celotni

organizaciji.

Kot smo že omenili, so integralni del procesa razvoja tudi podporna orodja. Orodja so

odličen pripomoček pri avtomatiziranju ponavljajočih opravil, ohranjanju strukturiranosti

entitet, upravljanju velikih količin informacij in vodenju skozi določene razvojne poti. Brez

uporabe orodij, ki avtomatizirajo konsistenco, bi bilo zelo težko, če ne nemogoče,

usklajevati najnovejše verzije modelov z implementacijo, kar bi drastično znižalo

produktivnost projektne skupine in kakovost izdelkov ter podaljšalo razvojni cikel [3]. Še

težje pa bi bilo inkrementalno in iterativno razvijati programske sisteme in informacijske

rešitve. Danes so na tržišču orodja, ki podpirajo vsak vidik življenjskega cikla procesa, in

sicer upravljanje zahtev, vizualno modeliranje, zagotavljanje kakovosti in implementacijo

ter tudi takšna, ki so uporabna v celotnem življenjskem ciklu. Med slednje uvrščamo

orodja za nadzor verzij, upravljanja konfiguracij, sledenje napakam, dokumentiranje,

vodenje projektov pa tudi orodja, ki avtomatizirajo proces.

Proces, ki se uporablja v razvojnem projektu, ima pomemben vpliv na kakovost

programskih sistemov [20]. S tega vidika je zelo pomembno, da IT-podjetja/organizacije

neprestano izboljšujejo in vzdržujejo svoje procese razvoja z namenom povišanja njihove

zrelosti. V ta namen lahko uporabljajo ocenitvene modele, kot so ISO 9001-2008,

Software Process Improvement and Capability Determination (SPICE) ter Združeni

zrelostni zmožnostni model. Slednji bo opisan v naslednjem poglavju.

7

3 OCENITEV ZRELOSTI PROCESA RAZVOJA INFORMACIJSKIH REŠITEV

Združeni zrelostno zmožnostni model (angl. Capability Maturity Model Integration, CMMI)

je zrelostni model za izboljšanje procesov razvoja rešitev in storitev. Sestavljajo ga

najboljše prakse, ki naslavljajo razvojne in vzdrževalne aktivnosti v celotnem življenjskem

ciklu rešitve, od koncepta do dobave in vzdrževanja [12]. Uporabljamo ga lahko za

izboljšanje procesov v okviru projektov, oddelkov ali organizacije. Zrelost procesa razvoja

je obseg definiranosti, upravljanosti, merjenosti, nadzorovanosti in učinkovitosti

posameznega procesa razvoja informacijskih rešitev [8]. Model v osnovi uvaja disciplino v

razvoj programske opreme s formaliziranjem, standardiziranjem in institucionaliziranjem

določenega nabora procesov.

Model CMMI za razvoj, verzija 1.2, predlaga dva pristopa za izboljšanje in ocenjevanje

procesov z uporabo nadaljevalne (angl. continuous) ali stopenjske (angl. staged)

predstavitve [12]. Nadaljevalna predstavitev omogoča organizaciji, da izbere eno ali več

procesnih področij (vseh procesnih področij je 22) in izboljša procese, ki so povezani z

njimi. Ta predstavitev uporablja nivoje zmožnosti za označevanje izboljšanja glede na

posamezno procesno področje. Stopenjska predstavitev uporablja vnaprej definirano pot

izboljšav za organizacije na osnovi zrelostnih nivojev. Vsak zrelostni nivo podaja niz

procesnih področji, ki okarakterizirajo obnašanje organizacije. Zrelostni nivoji rastejo od

nivoja ena (najnižji nivo), na katerega se uvrščajo organizacije s slabo definiranim

procesom, do nivoja pet, na katerem se nahajajo organizacije z zelo dobro organiziranim

procesom. Organizacije ob vzpostavljanju svojega procesa v časovnem zaporedju

prehajajo z nivoja ena do nivoja pet. Procesna področja so razporejena glede na njihov

vpliv na delovanje organizacije. Procesna področja, ki imajo največji vpliv na delovanje

organizacije, so uvrščena na prehode med nižjimi nivoji [25]. Torej, stopenjska

predstavitev podaja smernice glede izboljšav v smislu področij, ki jih najprej izboljšujemo.

Model definira šest zmožnostnih in pet zrelostnih nivojev, kot je razvidno iz tabele 1.

8

Tabela 1: Nivoji nadaljevalne in stopenjske predstavitve modela CMMI [12]

Nadaljevalna predstavitev (zmožnostni nivoji)

Stopenjska predstavitev (zrelostni nivoji)

Nivo 0 nepopoln -

Nivo 1 izvajani začetni

Nivo 2 voden voden

Nivo 3 definiran definiran

Nivo 4 kvantitativno voden kvantitativno voden

Nivo 5 optimizacijski optimizacijski

V nadaljevanju bomo na kratko opisali značilnosti procesa na posameznem nivoju zrelosti.

Podroben opis je podan v [12].

Zrelostni nivo 1 – Začetni

Začetni nivo opisuje začetno stanje procesa v organizacijah in je osnova za njegovo

izboljševanje. Številne organizacije delujejo na tem nivoju, ki bi ga lahko opisali kot bolj ali

manj nadzorovan kaos. Kljub temu organizacije, ki dosegajo začetni nivo, izdelujejo

delujoče programske proizvode in storitve, vendar pogosto izven planiranega okvira

proračuna in časovnice, saj so obveze do naročnikov nenadzorovane in zato večinoma

neizpolnjene pa tudi sistematično in ponovljivo izvajanje najboljših praks razvoja

programske opreme je bolj izjema kot pravilo. Uspeh teh organizacij je odvisen od

kompetentnosti in prizadevanj posameznikov in ne od uporabe preizkušenih procesov, kar

pomeni, da so procesi na tem nivoju primerni za projekte z enim članom. Razvojno okolje

se na začetnem nivoju v vsaki situaciji obnaša naključno. Proces se razvija po nekih

ustaljenih postopkih, ki pa so v podobnih situacijah nekoliko drugačni in zato nepredvidljivi

[24]. Uporabnikove zahteve po spremembah, fluktuacija kadrov in nove zaposlitve

povzročajo velike težave. Tipično za okolje na začetnem nivoju je obnašanje v kritičnih

situacijah. Problemi se začnejo in končajo reševati s popravkom kode programov. Čeprav

je to večinoma nujno, pa vsi pozabijo, da ima vsaka napaka ali sprememba svoj vzrok in

posledice, ki so enako pomembne, kot je odprava same napake. Razvojno okolje v

začetnem nivoju ne spremlja stroškov svojega dela, redko ali "ad hoc" načrtuje, še redkeje

pa primerja načrtovano z opravljenim. Razna orodja (kupljena, lastna) se uporabljajo

neučinkovito ali le delno. Ali lahko v takem okolju opravičimo nakup dragega orodja

CASE? Ali znamo povedati, za koliko odstotkov bomo dvignili produktivnost z nakupom

takega orodja [24]?

9

Zrelostni nivo 2 – Voden

Na vodenem nivoju je zagotovoljeno, da so procesi planirani in izvajani v skladu z

definirano politiko. Voden proces je nadzorovan, spremljan in pregledovan, izvajajo ga

izkušeni ljudje, ki imajo na razpolago ustrezne vire za razvoj nadzorovanih izhodov (npr.

izdelkov, planov, ocen), vključuje ustrezne deležnike in je ocenjen glede na skladnost z

opisom. Procesna disciplina na vodenem nivoju zagotavlja, da projektna skupina tudi v

stresnih situacijah redno in ponovljivo izvaja osnovne prakse. Uporaba teh praks

zagotavlja, da se projekti izvajajo in upravljajo v skladu z dokumentiranimi plani. Status

izdelkov in predaja storitev sta vidni vodstvu na določenih točkah v projektu (npr. glavni

mejniki, dokončanje pomembnih opravil). Obveznosti med deležniki so urejene in so po

potrebi znova pregledane. Izdelki so primerno nadzorovani. Izdelki in storitve so v skladu

z njihovimi specifikacijami, podanimi v opisu pocesa, standardih in postopkih. Če je

razvojno okolje uspelo implementirati upravljanje zahtev, planiranje projektov, nadzor in

spremljanje projektov, upravljanje sporazumov z dobavitelji, merjenje in analizo,

zagotavljanje kakovosti procesa in proizvoda ter upravljanje konfiguracije, ki predstavljajo

procesna področja vodenega nivoja, je to za razvojno okolje tak napor in napredek, da

velja prepričanje, da so rešeni vsi organizacijski problemi procesa [24]. Okolje dosega

ponovljive rezultate, vendar se ne zaveda, da jih dosega zaradi čvrste organizacije in

kontrole že usvojenega znanja. Razvojno okolje je prepričano, da so rešeni vsi problemi.

Prednost ponovljivega procesa pred začetnim je v tem, da v njem že lahko nadziramo

način, kako je organizacija vpeljala v svoje delo planiranje in obveze. Organizacije, ki so

dosegle nivo ponovljivosti procesa, so lahko zelo uspešne pri izvajanju procesov, ki so si

podobni glede na strukturo in zahteve [25].

Nova tveganja in težave pa nastopijo pri uvajanju novih tehnologij in metod dela, izdelavi

novega proizvoda ali večji spremembi na uporabniški strani ter pri večjih organizacijskih in

kadrovskih spremembah v razvojnem okolju [24]. Za rešitev teh težav je potrebno v

organizaciji postaviti standardni proces oz. niz standardnih procesov. Uvesti je potrebno

aktivnosti in skupine, ki se bodo posvetile samo oblikovanju in vzpostavitvi tega procesa v

organizaciji [25].

10

Zrelostni nivo 3 – Definiran

Definiran proces je voden proces, ki je prilagojen na osnovi standardnega nabora

procesov organizacije z upoštevanjem organizacijskih smernic za prilagajanje, njegov opis

se uporablja in izvajanje procesa prispeva k vrednostim organizacijskega procesa (angl.

organizational process asset) koristne rezultate, meritve in ostale informacije, ki zadevajo

izboljševanje procesa [12]. Na tem nivoju je vzpostavljen nabor standardnih procesov

organizacije, ki se s časom izboljšujejo in opisujejo osnovne procesne elemente, za katere

se pričakuje, da bodo vključeni v definirane procese. Standardni procesi opisujejo tudi

relacije med procesnimi elementi (npr. vrstni red in vmesnike). Na nivoju organizacije je

vzpostavljena infrastruktura, ki podpira trenutno in prihodnjo uporabo nabora

organizacijskih procesov. Definiran proces projekta jasno določa vhode, izhode, vhodne in

izhodne kriterije, merila, aktivnosti, vloge in korake za izvajanje verifikacije ter zagotavlja

osnovo za planiranje, izvajanje in izboljševanje opravil in aktivnosti projekta [12].

Razlika med vodenim in definiranim procesom je področje uporabe standardov, opisov

procesa in procedur. Za voden proces so opisi procesov, standardi in postopki uporabni

za posamezne projekte, skupine ali organizacijske funkcije in zato se lahko v IT-

organizaciji vodena procesa dveh projektov med seboj razlikujeta. Voden in definiran

proces se razlikujeta tudi v tem, da je definiran proces bolj podrobno opisan in bolj

rigorozno izvajan, kar pomeni, da informacije, ki se tičejo izboljšanja, lažje razumemo,

analiziramo in uporabljamo. Osnovo za upravljanje definiranega procesa zagotavlja

razumevanje medsebojnih povezav procesnih aktivnosti in podroben opis meril procesa,

njegovih koristnih rezultatov in storitev, kar pa ni značilno za voden proces [12].

Pri razumevanju in definiranju procesa gre za zelo različna znanja in sposobnosti. Zato je

potrebno za to nalogo izbrati v velikih razvojnih okolji (100 in več delavcev) posebno

skupino. V manjših razvojnih okoljih pa je smiselno osnovati skupino, kateri je poleg

ostalih nalog dodeljena še naloga spremljati in analizirati lasten proces in nove

tehnologije. Če je lastnega znanja premalo ali pa ni dovolj upoštevano, moramo poiskati

zunanje konzultante. [24]

11

Zrelostni nivo 4 – Kvantitativno voden

Kvantitativno voden proces je definiran proces, ki je nadzorovan z uporabo statističnih in

drugih kvantitativnih tehnik. Skupaj s kakovostjo izdelkov in storitev so ves čas trajanja

projekta merljivi in nadzorovani tudi atributi učinkovitosti procesa. Učinkovitost procesa je

definirana kot opis aktualnih rezultatov, doseženih z udejanjanjem procesa [8].

Vzpostavljeni so kvantitativni cilji glede na zmožnost (sposobnost) nabora standardnih

procesov, poslovnih ciljev organizacije in potreb naročnikov, končnih uporabnikov,

organizacije ter odgovornih za implementacijo procesa. Zaposleni, ki izvajajo proces, so

neposredno vključeni v kvantitativno vodenje procesa. Kvantitativno vodenje se izvaja na

celotnem sklopu procesov, ki proizvajajo informacijsko rešitev. Podprocesi, ki vplivajo na

celotno učinkovitost procesa, so statistično vodeni. Učinkovitost procesa je v teh

segmentih podrobno merjena in statistično analizirana. Posebni vzroki za variacije v

procesu se identificirajo in kadar je potrebno se z namenom preprečitve ponovitve

naslovijo tudi razlogi zanje. Merila kakovosti in učinkovitosti procesa so vključena v merski

repozitorij organizacije in tako omogočajo sprejemanje bodočih odločitev na podlagi

dejstev.

Razlika med definiranim in kvantitativno vodenim procesom je predvidljivost učinkovitosti

procesa. Izraz kvantitativno voden pomeni uporabo ustreznih statističnih in drugih

kvantitativnih tehnik za vodenje učinkovitosti enega ali več podprocesov z namenom

predvidljivosti učinkovitosti celotnega procesa. Pri kvantitativno vodenem procesu je

predvidljivost učinkovitosti procesa kvantitativno določena, kar pa ne velja za proces na

tretjem nivoju, kjer je predvidljivost učinkovitosti kvalitativna [12].

Zrelostni nivo 5 – Optimizacijski

Na tem nivoju organizacija stalno izboljšuje svoje procese na način, da kvantitativno

razume variacije v procesih, ki so rezultat običajnih in pričakovanih interakcij med

elementi procesa. Procesna učinkovitost se izboljšuje zaradi inkrementalnega in

inovativnega procesa ter tehnoloških izboljšav. Kvantitativni cilji organizacije, ki se tičejo

izboljšav, so vzpostavljeni, stalno pregledovani in uporabljeni kot kriteriji za vodenje

izboljšav procesa. Učinki uporabljenih izboljšav procesa so merjeni in ocenjeni glede na

kvantitativno postavljene cilje. Merljive aktivnosti izboljšanja se uporabljajo na definiranih

procesih kot tudi na skupku organizacijskih standardnih procesov [12].

12

Razlika med nivojema štiri in pet je vrsta variacije procesa. Kvalitativni proces naslavlja

posebne vzroke (angl. special causes) za variacije v procesu in zagotavlja statistično

predvidljivost rezultata [12]. Čeprav so lahko rezultati procesa predvidljivi, pa so lahko ti

neprimerni za doseganje postavljenih ciljev. Optimizacijski proces naslavlja normalne in

pričakovane vzroke (angl. common causes) za variacije v procesu in izboljšave procesne

učinkovitosti ter doseganje postavljenih kvantitativnih ciljev za izboljšanje procesa s

spreminjanjem procesa.

CMMI Institute vsake pol leta objavi podatke o profilu zrelosti ocenjenih organizacij. V

aktualnem poročilu [28] je med ocenjenimi 5500 organizacijami 1 % organizacij na prvem,

začetnem nivoju, 24,6 % na vodenem nivoju, 63,3 % na definiranem, 1,7 % na četrtem in

6,2 % organizacij na petem zrelostnem nivoju.

Če želijo IT-podjetja/organizacije doseči vsaj definiran nivo, takšnih je po zgornjih podatkih

večina, lahko uporabijo prilagodljive komercialne pristope, ki so jih razvila nekatera

vodilna podjetja v IT-industriji in jih tudi zelo uspešno uporabljajo pri lastnem razvoju (npr.

IBM, Microsoft, Fujitsu, HP), pa tudi številne prosto dostopne procese, npr. OPF (OPEN

Process Framework). Več v naslednjem poglavju.

13

4 PROCESNA OGRODJA ZA RAZVOJ INFORMACIJSKIH REŠITEV

Izdelava informacijskih rešitev znotraj proračuna, v dogovorjenem obsegu in časovnih

okvirih zahteva urejen pristop. V ta namen IT-industrija uporablja referenčne metodologije,

da lahko obdrži projekte na pravi poti. Med temi so tudi takšne, ki niso primerne v

današnjem času e-poslovanja, porazdeljenih sistemov in hitrih sprememb, saj so pogosto

premalo fleksibilne in večinoma temeljijo na slapovnem življenjskem ciklu. To potrjuje tudi

leta 2009 objavljena študija Standish Group, ki pove, da se je zgolj 32 odstotkov projektov

razvoja IT-rešitev uspešno zaključilo in da je takih, ki so propadli, 24 odstotkov. Preostalih

44 odstotkov se je zaključilo s prekoračenim proračunom in/ali veliko zamudo [17].

Podane številke kar kličejo po uporabi ustreznih razvojnih referenčnih metodologij oz.

referenčnih procesov razvoja.

Različni tipi sistemov potrebujejo različne metodologije oz. razvojne procese, ki jih delimo

na lažje in težje. Med lažje uvrščamo agilne metode(logije), ki se večinoma uporabljajo za

hiter razvoj poslovnih informacijskih sistemov, kjer se zahteve med razvojem veliko

spreminjajo. Te metodologije ne temeljijo na procesu in dokumentaciji, ampak na ljudeh in

delujoči programski opremi. Med konvencionalne metodologije pa uvrščamo tiste, ki

podrobno opišejo korake razvoja, njihove medsebojne povezave in pogoje, vloge, vhodne

in izhodne izdelke, podajajo obsežne napotke, smernice itd. Na primer programski sistemi

v letalih, ki delujejo v realnem času, morajo biti pred začetkom razvoja v celoti

specificirani, kar pomeni težji proces. To pa ne velja npr. za sisteme elektronskega

poslovanja. Pri razvoju teh sistemov se specifikacija in informacijska rešitev običajno

razvijata sočasno. Posledično to pomeni, da morajo biti temeljne aktivnosti, ki se

uporabljajo v projektih razvoja programskih rešitev, organizirane na različne načine in

opisane z različno stopnjo podrobnosti.

Med metodologijami, ki jih lahko danes najdemo na tržišču, so tudi takšne, ki se lahko

prilagodijo kompleksnosti projekta, zrelosti in kulturi organizacije, tipu razvoja, velikosti

organizacije in zahtevam predpisov ter politik. Imenujemo jih procesna ogrodja. Procesno

ogrodje lahko definiramo tudi kot strukturo ali okvir, načrtovano z namenom, da nekaj

14

podpira – je skupek komponent, ki jih lahko prilagajamo in sestavljamo v celoto [5]. Tabela

2 podaja nekatere karakteristike procesnih ogrodij Open UP, RUP SOMA (Service

Oriented Modeling and Architecture), MSF Agile software Development, RUP in MSF.

Tabela 2: Atributi procesnih ogrodij

RUP 7.0 MSF 4.0 Open UP 1.5 RUP SOMA 2.4

MSF Agile Software Development 4.2

Kategorizacija generično procesno ogrodje

generično procesno ogrodje

procesno ogrodje

procesno ogrodje

procesno ogrodje

Komercialnost / podjetje

da / IBM da / Microsoft ne / odprta rešitev

da / IBM da / Microsoft

Dokumentacija (HTML)

Da, privzeta spletna stran, generirana s podpornim orodjem.

Ne, knjiga [7]. Da, Wiki spletna stran.

Da, privzeta spletna stran, generirana s podpornim orodjem.

Da, procesni napotki agilne šablone v podpornem orodju (Visual Studio 2008 Team System Suite).

Podporna orodja za prilagajanje

Rational Method Composer v.7.5

ne

Eclipse Process Framework Composer v.1.5.1.4

Rational Method Composer v.7.5

Visual Studio 2008 Team System Suite, Visual Studio 2008 Team Foundation Server

Modelirni jezik

UML ni opisan UML UML ni opisan

Pokritost celotnega življenjskega cikla

da

da

da

da

da

Različni pogledi da

da da da da

Aktivnosti prilagajanja

da ne da ne ne

Ta standardna, izdana procesna ogrodja morajo organizacije prilagoditi svojim potrebam z

upoštevanjem naslednjih dejavnikov [14]:

● organizacijski: zmožnost sprememb, organizacijska struktura, organizacija in

upravljanje projektov, kompetence in veščine, izkušnje ter obstoječi programski

sistemi,

● domenski: domena aplikacije, poslovni proces, ki ga je potrebno podpreti, skupina

uporabnikov in ponudba konkurence,

● življenjski cikel: čas, potreben za dostavo in pričakovana življenjska doba programske

rešitve, tehnologija, strokovno znanje ter planirane izdaje in

15

● tehnični: programski jeziki, razvojna orodja, podatkovna baza, ogrodja, standardne

arhitekture, komunikacije in porazdeljenost.

V IT-podjetjih/organizacijah je vloga prilagajanja namenjena procesnim inženirjem, ki

potrebujejo znanja s področja procesnega inženirstva, ki ga lahko opredelimo kot proces

prilagajanja in/ali izboljševanja procesov razvoja (procesnih ogrodij) na nivoju organizacije

ali projektov na osnovi prilagajanja standardnega procesnega ogrodja. Proces prilagajanja

se izvaja po (najmanj) treh scenarijih, kot prikazuje Slika 1.

Slika 1: Scenariji prilagajanja procesnega ogrodja – prirejeno po [22]

V scenariju A (prilagajanje generičnega ogrodja projektu), se ogrodje prilagodi

posameznemu projektu v enem koraku, kar predstavlja naporno delo. To je mogoče

upravičiti zgolj za velike projekte, kjer sam proces prilagajanja postane le majhen del

16

skupne količine dela na projektu. V scenariju B (prilagajanje na nivoju organizacije)

organizacija zgradi podmnožico generičnega procesnega ogrodja, ki ima še zmeraj

lastnost ogrodja in se nanaša na splošne lastnosti organizacije. V scenariju C (prilagajanje

na nivoju tipov projektov organizacije) organizacija najprej identificira in opiše množico

tipov projektov, ki jih izvaja (npr. razvoj novih aplikacij, vzdrževanje obstoječih aplikacij).

Ob poznavanju lastnosti in razlik med posameznimi tipi projektov se izvede prilagajanje

organizacijskega ogrodja posameznim tipom projektov. Organizacija lahko na tem nivoju

uporabi tudi standardna procesna ogrodja (npr.OpenUP) in jih ustrezno prilagodi lastnim

potrebam (slika 1). Organizacija v tem scenariju tako zgradi z ozirom na število različnih

tipov projektov določeno število projektno tipskih procesnih ogrodij. Iz slike 1 je razvidno,

da je zadnji korak v vsakem od scenarijev prilagajanje določenega tipa procesnega

ogrodja posameznemu projektu (prilagajanje na nivoju projektov). V primeru scenarija C

se pred izvajanjem projekta postavi vsaj eno ogrodje (npr. prilagojeno ogrodje OpenUP) in

začetni razvojni primer (angl. development case), ki se med samim izvajanjem projekta

dopolnjuje. V splošnem je izvajanje procesa prilagajanja upravljanje z znanjem, saj se

izkušnje pridobljene z izvajanjem prilagajanj in znanje, skrito in eksplicitno, strukturira,

dokumentira in posreduje v obliki končnega razvojnega procesa oz. končnega razvojnega

primera [22].

17

5 OGRODJE RUP

RUP je procesno ogrodje, ki zagotavlja okvir za procese razvoja programske opreme in je

uveljavljeno v IT-industriji. Voden je s primeri uporabe, osredotočen na arhitekturo in

obvladovanje tveganj ter uporabljen iterativno in inkrementalno. Je dobro definiran (kdo,

kaj, kako in kdaj), strukturiran ter dokumentiran. Podaja smernice za širok nabor principov

programskega inženirstva in ga je mogoče uporabiti v projektih različnih velikosti in

kompleksnosti kot tudi v različnih razvojnih okoljih in domenah. Ogrodje se nahaja v

obsežni knjižnici IBM RUP orodja RMC, ki je komercialna procesna platforma korporacije

IBM za disciplino procesnega inženiringa [4]. Platforma je namenjena procesnim

inženirjem, vodjem projektov ter projektnim in programskim menedžerjem, ki so odgovorni

za definiranje in vzdrževanje procesov razvoja informacijskih rešitev na nivoju organizacij

in/ali posameznih projektov.

Ogrodje procesnim inženirjem omogoča definiranje procesov, ker jim zagotovlja dobro

arhitekturno osnovo oz. strukturo (več o tem v poglavju 5.2), ki jo lahko po želji

spreminjajo, prilagajajo in razširjajo. Na ta način prihranijo čas in trud, saj bi sicer morali

posameznim projektom prilagojene procesne definicije razvijati od začetka [14]. Klasična

konfiguracija RUP, ki je namenjena obsežnim projektom, je z uporabo platforme RMC tudi

objavljena in je s preprostim kopiranjem na spletni strežnik podjetja kot interaktivna

spletna stran z uporabo standardnih brskalnikov tudi široko dosegljiva. Avtomatizacija

procesa poveča njegovo vrednost, zato je RUP tesno povezan z razvojnimi orodji in kot

tak tudi sestavni del razvojnega okolja. Tesna povezava je realizirana s kontekstno

odvisnimi procesnimi napotki, ki so dostopni v razvojnih orodjih in z mentorji za orodja,

dostopnimi v opisu procesa. Hkrati je tesno povezan tudi z orodji, ki omogočajo

oblikovanje primerka procesa, prilagodljivo planiranje projektov in skupinski razvoj

programske opreme. Kljub temu pa je RUP neodvisen od orodij [23].

18

5.1 Zgodovina

Ogrodje RUP se je razvijalo skozi leta in odraža kolektivne izkušnje številnih ljudi in

podjetij. Rational Objectory Process (ROP), verzija 4.1, je neposredni predhodnik prve

verzije ogrodja RUP 5.0 iz leta 1998. Na zasnovo ROP in posledično tudi RUP sta imela

močan vpliv Rational Approach, predvsem njegova koncepta iterativnega razvoja in

arhitekture, in leta 1988 razvit Objectory Process 3.8, od katerega je ROP podedoval

procesni model in koncept primera uporabe [4, 16]. Modelirni jezik Unified Modeling

Language (UML) 0.8 je bil prvič uporabljen v ROP 4.0. Dolga zgodovina in jasno sledenje

verzijam iterativnega razvojnega procesa RUP vse do leta 2005, kot prikazuje slika 2, je

edinstveno v IT-industriji [4].

Slika 2: Evolucija RUP [4]

19

Mejnik v razvoju procesnega ogrodja RUP leta 2005 je bistveno spremenil distribucijo,

konfiguracijo in postavitev RUP [4]. Spremenila sta se namreč metamodel in procesna

platforma RUP (proizvod RUP in orodje Rational Process Workbench), saj sta bila

uvedena Unified Method Architecture (UMA) in IBM Rational Method Composer (RMC).

Najnovejša IBM-ova procesna platforma RMC temelji na Eclipsu in nadomešča orodja

RUP (Rational Process Workbench (RUP Modeler in RUP Organizer), RUP Builder ter

MyRUP), ki so se uporabljala za prilagajanje ogrodja RUP. IBM Rational, ki je odgovoren

za razvoj ogrodja RUP, je leta 2005 doniral fundaciji Eclipse tako podmnožico procesnega

ogrodja RUP, znano kot Basic Unified Proces (BUP), ki se je leta 2006 v sklopu projekta

Eclipse Process Framework razširil in preimenoval v Open Unified Process (Open UP) kot

tudi osnovne zmožnosti platforme RMC. Nova procesna platforma Eclipse Process

Framework Composer je na voljo brezplačno kot odprtokodna aplikacija. V obdobju med

letoma 2005 in 2013 se je ogrodje le enkrat in še to le minimalno spremenilo (verzija 7.0 v

verzijo 7.0.1). Od leta 2011 poteka razvoj ogrodja v smeri praks (angl. practices) in se

nadaljuje v knjižnjici IBM Practices ogrodja RMC. Slika 3 prikazuje prosto dostopno bazo

znanja RUP orodja RMC, ki se uporablja za razvoj (angl. authoring), konfiguracijo (angl.

configuration), predogled (angl. viewing) in objavo (angl. publishing) procesov razvoja.

Slika 3: Orodje RMC in baza znanja RUP [4]

20

5.2 Struktura ogrodja RUP

Ogrodje RUP je organizirano v dve dimenziji, kot prikazuje slika 4.

Slika 4: Ogrodje RUP [4]

Vertikalna dimenzija prikazuje discipline RUP (opisane so v poglavju 5.5) oz. vsebino,

horizontalna dimenzija pa predstavlja čas in prikazuje vidik življenjskega cikla ogrodja

RUP oz. proces.

Slika 5 prikazuje iterativno in inkrementalno naravo ogrodja RUP. Osnovna ideja tega

pristopa je inkrementalni (postopni) in iterativni (ponavljajoč) razvoj programskega sistema

v okviru življenjskega cikla, ki je opisan s fazami, iteracijami in mejniki na koncu vsake od

faz. Programski produkt gradimo inkrementalno (v korakih) in vsaka naslednja iteracija

predstavlja njegov inkrement. Tak proces zmanjšuje tveganje za neuspeh projektov, saj

omogoča dovolj zgoden razvoj in preizkušanje najbolj kritičnih delov sistema. Glede na

21

dejstvo, da se v vsaki iteraciji razvije izvedljiva podmnožica sistema, omogoča ogrodje

hitro odkrivanje protislovij v zahtevah, načrtovanju in implementaciji. Iterativni pristop, ki

ga uporablja ogrodje RUP, omogoča deležnikom razumevanje problema postopoma skozi

posodobitve kot tudi inkrementalni razvoj učinkovite rešitve, ki izpolnjuje naročnikove

zahteve skozi več iteracij. Vsaka iteracija se zaključi z izvedljivo izdajo (angl. release), kar

zagotavlja vključevanje in povratne informacije končnih uporabnikov. Takrat se tudi

preveri status projekta, kar omogoča razvijalcem osredotočanje na svoje delo in

poslovnim deležnikov zagotovilo, da projekt ostaja znotraj dogovorjenih okvirov [19].

Življenjski cikel RUP sestavljajo štiri zaporedne faze: začetna, zbiranje informacij,

konstrukcija in prevzem in so podrobno opisane v podpoglavju 5.4. Znotraj posameznih

faz poteka razvoj v iteracijah, vertikalno navzdol skozi discipline. Iteracije so usmerjene v

izdelavo tehničnih izdelkov, potrebnih za doseganje poslovnih ciljev posamezne faze. V

vsaki od faz se izvede toliko iteracij, kot je potrebno, da so zastavljeni cilji ustrezno

izpolnjeni, vendar ne več kot to. Izpolnitev ciljev iteracije premakne projekt bližje ciljem te

faze.

Slika 5: Iteracije – prirejeno po [4]

22

Predstavljena arhitektura poveže dva pogleda na razvoj informacijskih sistemov. Gledano

s časovne perspektive govorimo o fazah, ki jih delimo na razvojne cikle – iteracije in

mejnike. Tak pogled je značilen za upravljalski nivo gledanja na projekt (projektno

vodenje). Gledano s perspektive proizvodov pa delimo razvojni proces na posamezne

discipline [2]. Šest izmed njih je osnovnih in so neposredno povezane z aktivnostmi

programskega inženirstva. Te so: poslovno modeliranje, zahteve, inženiring zahtev,

analiza in načrtovanje, implementacija, testiranje in dobava. Preostale tri aktivnosti so

podporne, vendar krovne, ker se nanašajo na celovito upravljanje in strukturo RUP

projektov in naslavljajo upravljanje konfiguracije in sprememb, vodenje projektov in okolje.

V nadaljevanju bodo predstavljeni osnovni elementi (koncepti) ogrodja oz. elementi

vsebine metode in procesa. Prikazuje jih slika 6.

Slika 6: Osnovni elementi ogrodja RUP [4]

5.2.1 Osnovni elementi vsebine

Vsebina metode opisuje kako pogosto, korak za korakom, doseči specifične razvojne cilje,

kdo naj bo vključen, vhode, potrebne za začetek dela, in izhode, ki so pogosto rezultat

izvajanja razvojnih metod. Ti vhodi in izhodi so v ogrodju RUP poimenovani izdelki.

Vsebina tako naslavlja kako (opravila in aktivnosti), kdo (vloga) in kaj (izdelki) – slika 7. Če

vloga potrebuje pomoč, opravilo in/ali izdelek pa bolj podroben opis, so za pojasnitev

23

pridruženi ustrezni napotki (angl. guidance). Zaradi obsežnosti in kompleksnosti je

vsebina kategorizirana v devet disciplin, ki so opisane v podpoglavju 5.5.

Slika 7: Konceptualni model ključnih konceptov [1]

Izdelek (angl. Artifact)

Izdelek je v metodologiji RUP dobro definiran delovni izdelek (angl. work product), ki ga

vloge uporabljajo, proizvajajo ali spreminjajo v okviru izvajanja opravil. Lahko je sestavljen

tudi iz drugi izdelkov. Odgovornost za določeno vrsto izdelka je dodeljena zgolj eni vlogi,

vendar lahko tudi druge vloge ob dovoljenju vloge lastnice uporabljajo ali celo

posodabljajo izdelke. Izdelki so lahko različnih oblik kot na primer model, element modela,

dokumenti, izvorna koda, izvršljivi programi. Ogrodje priporoča pristop vzdrževanja

projektnih izdelkov z orodji, s katerimi so bili ustvarjeni. Nad izdelki se največkrat izvaja

upravljanje konfiguracije in verzioniranje. Če ne moremo verzionirati posameznih izdelkov,

verzioniramo izdelek, ki vključuje druge izdelke (npr. verzioniziramo celoten model

načrtovanja in ne posameznih razredov, ki so v njem).

Vloga (angl. Role)

Vloga opredeljuje vedenje in odgovornosti pozameznika ali množice posameznikov, ki

delujejo kot skupina v okviru poslovne organizacije. Vedenje se odraža v opravilih, ki jih

vloge izvajajo in posamezna vloga je povezana z množico opravil. Odgovornosti vsake od

vlog so navadno izražene v povezavi z določenimi izdelki, ki jih vloga ustvari, spreminja ali

nadzira. Preko povezanega sklopa nalog pa implicitno opredeljuje tudi kompetentnost

24

(angl. competence). Pomembno je opozoriti, da vloga ni naziv delovnega mesta niti

posamezniki, ampak zgolj opisi, kako se naj ti v poslovanju obnašajo in kakšne

odgovornosti naj prevzemajo. Tako lahko nekdo igra vlogo vodje projekta eno uro, nato

preostanek dopoldneva vlogo arhitekta in popoldne izmenično vlogi programerja in

testerja. Pri določanju vlog oziroma nalog lahko projektni vodja določi več različnih vlog za

posameznika ali pa določi vlogo, katere naloge opravlja več posameznikov. Preslikavo

posameznika v vlogo izvaja vodja projekta v času planiranja in kadrovanja na osnovi

znanja, spretnosti in kompetenc.

Opravilo (angl. Task)

Opravilo, ki ga izvajajo vloge, opisuje enoto dela. Opravila so velikokrat premajhna za

namene planiranja in spremljanje napredka. Pogosto so za te namene boljša izbira

aktivnosti, ki združujejo določena opravila. Opravilo, ki ga opravljajo vloge, je dobro

definirano ciljno usmerjeno dejanje (npr. razvoj vizije) in je povezano z izdelavo ali

posodabljanjem enega ali le majhnega števila vhodnih in izhodnih izdelkov. Izvajanje

opravila običajno trajaja od nekaj ur do nekaj dni, kar pomeni, da se pogosto ponavlja v

iteracijah.

Korak (angl. Step)

Opis opravil pogosto vsebuje tudi izbirno množico korakov. Korak opisuje smiseln in

skladen del celotnega dela v opravilu. Koraki razmišljanja, koraki izvajanja in koraki

pregledovanja so tri kategorije, v katere so razvrščeni koraki.

Opisani elementi vsebine so kategorizirani v devet disciplin. Discipline so element

kategorij (ni prikazan na sliki 6) in logični vsebnik za zgoraj opisane gradnike in bodo

opisane v poglavju 5.6.

5.2.2 Napotki

Napotki, ki so opisani v tabeli 3, so opcijski (neobvezni) elementi ogrodja RUP, ki vključijo

v izdelke, opravila ali procesne elemente dodatno vsebino [4].

25

Tabela 3: Napotki ogrodja RUP [4]

VRSTA NAPOTKA

OPIS

Kontrolni seznam (angl. Checklist)

Omogoča specifikacijo nabora stavkov, ki se lahko uporabi pri preverjanju zaključka nabora aktivnosti ali se doda posameznim izdelkom. Ta napotek je še posebej uporaben pri preverjanju pregledov in statusa.

Koncept (angl. Concept)

Zagotavlja dodaten kontekst osnovnim idejam, ki se uporabljajo v elementu, na katerega se navezuje (npr. koncept disciplina lahko opisuje osnovne principe, motivacijo in prednosti grupiranja elementov v discipline).

Primer (angl. Example)

Prikazuje praktično uporabo izdelkov ali opravil.

Smernica (angl. Guideline)

Dopolni referenciran element z bolj podrobnimi informacijami. Še posebej je uporaben za začetnike, ki načeloma potrebujejo za dokončanje dela dodatno pomoč.

Praksa (angl. Practice)

Opisuje jasne, preizkušene strategije, ki so uporabne v različnih situacijah.

Poročilo (angl. Report)

Opisuje standarde za vnaprej definirane oblike ali razporeditve informacij kot tudi informacij, pridobljenih iz izdelkov.

Ponovno uporabno sredstvo (angl. Reausable Asset)

Koristni element, ki zagotavlja vrednost in kakovost. Rešitev je ponovno uporabno sredstvo, če zagotavlja vrednost v različnih situacijah v določenem kontekstu.

Procesna karta (angl. Roadmap)

Priključena aktivnostim z namenom vodenja uporabnikov skozi kompleksen proces od začetka do konca.

Podporno gradivo (angl. Supporting Material)

Vsak zahtevan napotek, ki ni skladen z nobenim drugim opisom napotka v tej tabeli.

Šablona (angl. Template)

Zagotavlja vnaprej definirano strukturo izdelkom in s tem zagotavlja konstistenco med istovrstnimi izdelki.

Usmeritve (angl. Whitepaper)

Poveže izdano usmeritev s procesom in tako dodatno opiše koncept, na katerega se nanaša, različne perspektive in mnenja. Usmeritve so navadno napisane in izdane neodvisno od procesa.

Mentorji za orodja (angl. Tool Mentor)

Večina projektov uporablja različna orodja z namenom bolj učinkovitega in produktivnega razvoja IT-rešitev. Mentorji za orodja zagotavljajo tehnične in konceptualne informacije o tem, kako uporabiti različna orodja za posamezne vidike procesa.

5.2.3 Osnovni elementi procesa

Koncepti (elementi) na desni strani slike 6 se v ogrodju uporabljajo za predstavitev

procesov. Glavni koncept je aktivnost, ki je lahko gnezdena in tako definira razčlenitvene

strukture. Medsebojna povezanost aktivnosti opredeli tok dela. Proces tako naslavlja kdaj

(delovni tok), torej četrti vidik sistematičnega pristopa k razvoju informacijskih rešitev.

Aktivnosti referencirajo vsebino z uporabo deskriptorjev in so namenjene definiranju

procesov. Ogrodje vsebuje dve vrsti procesov, in sicer zmožnostne vzorce (angl.

capability patterns) ter proces (angl. delivery process) [1].

26

Aktivnost (angl. Activity)

Aktivnost je temeljni koncept za definiranje procesov. Aktivnost definira strukture

razčlenitve dela in pretok dela. Lahko vsebuje deskriptorje, ki so reference na opravila,

vloge in izdelke.

Zmožnostni vzorec (angl. Capability Pattern)

Zmožnostni vzorci so nepopolni fragmenti (delčki) procesa, ki lahko vsebujejo aktivnosti in

mejnike. Združevanje sorodnih procesnih elementov v zmožnostne vzorce omogoča

procesnim inženirjem ponovno uporabo vzorcev in hitrejšo izgradnjo procesov.

Proces (angl. Delivery Process)

Proces je celotni (angl. end-to-end) življenjski cikel projekta in je zgrajen iz množice

elementov, ki jo sestavljajo aktivnosti, faze, iteracije, zmožnostni vzorci in mejniki.

Element procesa faza (ni prikazan na sliki 6) bo opisan v poglavju 5.5.

5.3 Značilnosti ogrodja RUP

RUP vsebuje številne dobre prakse, ki jih navadno uporabljajo uspešna IT-podjetja in

organizacije, saj njihova uporaba v različnih kombinacijah rešuje vzroke problemov, ki se

pojavljajo pri razvoju sistemov [16]. V nadaljevanju bomo opisali šest najboljših praks, in

sicer iterativni razvoj, vizualno modeliranje, preverjanje kakovosti, uporaba komponentnih

arhitektur ter nadzor nad spremembami. V letu 2005 so pri IBM nadgradili šest najboljših

praks s šestimi osnovnimi principi, ki so značilni za poslovno usmerjen razvoj.

5.3.1 Najboljše prakse

Iterativni razvoj

Današnji programski sistemi imajo obsežne in kompleksne strukture, ki onemogočajo

vnaprejšnje razumevanje celotnega sistema in vseh zahtev. Tako je nemogoče

27

zaporedoma opredeliti celotni problem, načrtovati celotno rešitev, zgraditi in na koncu

testirati celotni sistem. Iterativni razvoj omogoča projektu, da napreduje v majhnih,

kontroliranih korakih, ki se imenujejo inkrementi. Iteracije so načrtovane v obliki ciljev,

števila, trajanja, definicij opravil in odgovornosti. Vrstni red iteracij v okviru posameznih faz

življenjskega cikla pogojuje velikost tveganja. Ugotovljene težave v zgodnji fazi

zmanjšujejo tveganja projekta. Ta pristop omogoča tudi lažje udejanjanje taktičnih

sprememb, ki zadevajo spremembe v zahtevah, časovnici, proračunu in lastnostih

sistema.

Vizualno modeliranje

Model je poenostavitev realnosti, ki v celoti opisuje sistem z določenega vidika. Modele

gradimo, da bolje razumemo sistem, ki ga gradimo in da lažje obvladujemo kompleksnost

sistemov, saj ne moremo dojeti takšnih sistemov v celoti. Modeliranje je pomembno, saj

pomaga razvojni skupini vizualizirati, specificirati, zgraditi in dokumentirati strukturo in

obnašanje arhitekture sistema. Z uporabo standardnega jezika za modeliranje lahko člani

razvojne skupine med seboj nedvoumno komunicirajo. Vizualno modeliranje prav tako

pomaga ohranjati konsistentnost med sistemskimi izdelki zajemanja zahtev, načrtovanja

in implementacije. V bistvu uporaba vizualnega modeliranja pomaga razvojni skupini pri

obravnavanju kompleksnosti programskih sistemov [16].

Preverjanje kakovosti

Najti in odpraviti težave, povezane s programsko opremo, je sto do tisočkrat dražje, ko je

programska oprema že enkrat v uporabi kot pred tem. Zaradi tega je pomembno, da se

nenehno ocenjuje kakovost sistema, in sicer funkcionalnost, zanesljivost ter zmogljivost

tako aplikacij kot sistema. Glavnino preverjanja predstavlja preverjanje funkcionalnosti

sistema, ki obsega pisanje testov za vsak posamezen scenarij oz. vidik želenega

obnašanja sistema.

Upravljanje zahtev

Izziv pri upravljanju zahtev predstavlja njihova dinamičnost oziroma njihovo spreminjanje

med razvojem informacijske rešitve. Za vse sisteme razen najbolj trivialnih je namreč

značilno, da jih pred pričetkom razvoja ni mogoče popolnoma in izčrpno opisati.

28

Upravljanje zahtev obsega aktivnosti izvabljanja, organiziranja in dokumentiranja

zahtevane funkcionalnosti in omejitev, vrednotenje sprememb teh zahtev in ocenjevanje

njihovih vplivov ter sledenje in dokumentiranje uskladitev in odločitev. Zato upravljanje

zahtev zagotavlja [16]:

● discipliniran pristop k upravljanju zahtev,

● komuniciranje, ki je osnovano na definiranih zahtevah,

● zahteve, ki jim lahko sledimo, filtriramo in prednostno obravnavamo,

● možnost za objektivno oceno funkcionalnosti in učinkovitosti in

● lažje odkrivanje nedoslednosti.

Uporaba komponentnih arhitektur

Arhitektura je skeletna struktura sistema in jo sestavljajo najpomembnejši gradniki sistema

(podsistemi in komponente) in njihovi vmesniki. Komponentno osnovan razvoj je

pomemben pristop k razvoju arhitekture sistema, saj omogoča ponovno uporabo in

uporabniško prilagoditev komponent, ki so dostopne v velikem številu komercialnih virov.

Izvajanje načrtovanja, implementacije in testiranja arhitekture zgodaj v razvojnem projektu

omogoča hitro naslavljanje ključnih tveganj, postopno povečevanje projektne skupine in

lažje uvajanje manj izkušenih sodelavcev v projektno skupino [11]. Gradnja stabilne

arhitekture je pomembna tudi zato, ker omogoča visoko stopnjo ponovne uporabe,

porazdelitev razvijalcev v več skupin, ločitev tistih delov strojne in programske opreme, ki

so lahko predmet sprememb, in olajša vzdrževanje sistema. Uporaba komponentnih

arhitektur skupaj s prakso iterativnega razvoja omogoča nenehno evolucijo arhitekture IT-

rešitve.

Nadzor nad spremembami

Razvoj večjih programskih sistemov zahteva sodelovanje velikih skupin razvijalcev, ki

običajno niso locirani skupaj. Zato skupno delo na več različnih iteracijah, izdajah,

proizvodih in platformah predstavlja velik izziv. Spremembe narejene tekom razvoja lahko

v takšnih pogojih pustijo na različnih delih rešitve velike posledice. Nadzor nad

spremembami zato zagotavlja [16]:

● definiran in ponovljiv delovni tok za obvladovanje sprememb v zahtevah,

29

● manj komunikacije glede zahtevkov za spremembe,

● izolirane delovne prostore, ki omogočajo vzporedno delo članov skupine,

● statistični podatki povezani s spremembami zagotavljajo dobro osnovo za objektivno

oceno statusa projekta,

● delovne prostore, ki vsebujejo vse izdelke, kar omogočakonsistentnost in

● posledice sprememb je mogoče oceniti in nadzorovati.

5.4 Faze ogrodja RUP

Življenjski cikel ogrodja RUP sestavljajo štiri zaporedne faze: začetna, zbiranje informacij,

konstrukcija in prevzem.

Začetna faza (angl. Inception phase)

Poglaviten cilj začetne faze je doseči soglasje med vsemi udeleženci v projektu o ciljih

življenjskega cikla projekta. Začetna faza je pomembna predvsem pri razvoju novih

aplikacij, kjer obstajajo precejšnja tveganja glede poslovanja in zahtev in jih je potrebno

nasloviti še preden se projekt nadaljuje. Za projekte izboljšav v obstoječem sistemu je

začetna faza krajša, vendar še zmeraj osredotočena na odgovor, ali je zamišljeno možno

narediti in če da, ali se splača. V začetni fazi se zbere večina zahtev in približno dvajset

odstotkov vseh, predvsem arhitekturno pomembnih, se podrobno opiše z uporabo

primerov uporabe v modelu primerov uporabe [11].

Cilji začetne faze so [4,14]:

● vzpostavitev obsega projekta in robnih pogojev, ki vključujejo operativno vizijo,

sprejemljive kriterije in vse, kar je v produktu zaželjeno in kar ne,

● identificiranje kritičnih primerov uporabe sistema, primarnih scenarijev delovanja,

ki bodo vodili h glavnemu načrtovanju,

● predstavitev in mogoče tudi demonstracija najmanj ene možne arhitekture glede

na nekatere primarne scenarije,

● ocenitev skupnih stroškov in urnikov za celoten projekt,

● ocenitev potencialnih tveganj in

● priprava podpornega okolja projekta.

30

Faza zbiranja informacij (angl. Elaboration phase)

Poglaviten cilj te faze življenjskega cikla RUP je postaviti oris (angl. baseline) arhitekture z

namenom zagotavljanja stabilne podlage za večji del načrtovanja in implementacije v fazi

konstrukcije. Arhitektura se razvija na osnovi najpomembnejših zahtev (tistih, ki imajo

velik vpliv na arhitekturo sistema) in ocen tveganj. Z namenom ovrednotenja stabilnosti

arhitekture se lahko izdela en ali več izvedljivih prototipov arhitekture. V fazi zbiranja

informacij se izvabijo in podrobno opišejo še dodatne zahteve. Na koncu te faze je

podrobno opisanih približno osemdeset odstotkov vseh zahtev [11].

Cilji faze zbiranja informacij so [4, 14]:

● zagotovitev, da so arhitektura, zahteve in plani dovolj stabilni in tveganja dovolj

obvladovana, da se lahko določijo stroški in časovni načrt za dokončanje razvoja,

● naslavljanje vseh arhitekturno pomembnih tveganj,

● vzpostavitev osnovne arhitekture, ki je izpeljana iz napisanih arhitekturnih scenarijev,

ki tipično izpostavi največja tehnična tveganja projekta,

● izdelava razvojnega prototipa za produkcijsko-kakovostne komponente kot tudi

enega ali več raziskovalnih prototipov za enkratno uporabo z namenom zmanjševanja

specifičnih tveganj, kot so:

● kompromisi povezani z zahtevami in načrtovanjem,

● ponovna uporaba in

● izvedljivost produkta,

● zagotoviti, da temeljno ogrodje arhitekture podpira zahteve sistema glede sprejemljivih

stroškov in časa in

● priprava podpornega okolja projekta.

Faza konstrukcije (angl. Construction phase)

Pomik od faze zbiranja informacij k fazi konstrukcije je v projektih RUP očiten. Viri se

večinoma povečajo, zaradi česar projekt napreduje hitreje (merjeno v dobavljeni

funkcionalnosti). Iteracije so navadno krajše, ker se na ta način spodbuja sodelovanje

uporabnikov z namenom uporabe njihove povratne informacije pri validaciji. Znotraj

projekta vodja projekta usmerja projekt in usklajuje sredstva ter terminski plan napram

želeni funkcionalnosti. Opis dodatnih primerov uporabe je v fazi konstrukcije bolj izjema

31

kot pravilo [11]. Med fazo konstrukcije se arhitekt programske opreme osredotoča na

razvijalce, da ti uporabljajo opredeljeno arhitekturo. Strategija testiranja se uresničuje z

izvajanjem testiranja in dnevno nadgradnjo z izvršljivimi komponentami kot izhodom na

koncu vsake iteracije. Faza konstrukcije je v nekem smislu proizvodni proces, ker je

poudarek na upravljanju virov in nadzorovanju operacij za optimizacijo stroškov, urnikov in

kakovosti. Ta faza običajno traja najdlje in v njej običajno sodeluje največ članov projekta,

saj je obseg dela navadno največji [16].

Cilje faze konstrukcije lahko strnemo v [4, 14]:

● minimizacija stroškov razvoja skozi optimizacijo uporabe virov z izogibanjem

odvečnih kot tudi ponovnih del in popravil,

● doseči ustrezno kakovost, kakor hitro je to mogoče,

● postaviti koristne verzije (alfa, beta itd.), kakor hitro je to mogoče,

● dokončanje analize, načrtovanja, razvoja in testiranja za vse zahtevane

funkcionalnosti,

● iterativni in inkrementalni razvoj celotnega produkta, ki je pripravljen za prenos k

uporabniku,

● presoditi, ali so izdelana programska oprema in uporabniki pripravljeni za opravljanje

vsakodnevnih nalog in

● doseči določeno stopnjo sočasnosti v delu razvojnih ekip.

Faza prevzema (angl. Transition phase)

Osnovni cilj te faze je zagotoviti, da je programska oprema na voljo uporabnikom za

uporabo. Faza prevzema lahko zajema več iteracij, vključuje testiranje produkta z

namenom priprave na izdajo in manjše prilagoditve na podlagi povratnih informacij

uporabnikov, ki predvsem zajemajo manjše popravke, konfiguracijo, instalacijo in

uporabnost izdelka.

Osrednji cilji te faze so [4, 14]:

● validacija novega sistema glede pričakovanj uporabnikov (z beta testiranjem),

● usposabljanje končnih uporabnikov in vzdrževalcev,

● po potrebi vključevanje skupin za marketing, distribucijo in prodajo,

32

● podati oceno orisov namestitve glede celotne vizije in meril sprejemljivosti za

izdelek,

● doseči samostojnost uporabnikov pri uporabi izdelka in

● doseči soglasje, da so orisi namestitve dokončani in konsistentni z evaluacijskimi

kriteriji vizije.

5.5 Discipline ogrodja RUP

Discipline oz. področja proučevanja so v ogrodju RUP zgrajene iz aktivnosti, ki jih

sestavljajo opravila, ki korak za korakom opisujejo, kako naj razvojna skupina dosega

posamezne razvojne cilje. Delovni tokovi disciplin modelirajo dinamiko posameznih

disciplin in torej odgovor na vprašanje kdaj.

Poslovno modeliranje (angl. Business modeling)

Danes skoraj ne srečamo več podjetja, ki ne bi imelo poslovnih procesov podprtih z

informacijskim sistemom (IS). Pri večini predstavlja IS temelj poslovnih sistemov in brez

njega podjetje ne bi moglo poslovati. Pomembno je, da IS učinkovito ter pravilno podpira

poslovne procese. Ko želimo opisati poslovni proces, uporabimo poslovno modeliranje, ki

ni nič drugega kot opis obstoječega stanja v neki organizaciji. Popišemo lahko vse

poslovne procese, lahko pa se osredotočimo na manjšo poslovno enoto ali samo segment

(domeno). Mnogo različnih udeležencev v razvoju programskega sistema, z različnimi

znanji in interesi, mora razumeti poslovanje. Poslovni model je zato potrebno opisati na

različne načine, z uporabo različnih diagramov in nivojev abstrakcije. Ogrodje RUP

zagotavlja postopek in notacijo (UML) za poslovno modeliranje. Uporaba standardnega

modelirnega jezika UML za modeliranje poslovanja in modeliranje programskega sistema

omogoča lažjo komunikacijo med skupinami, ki analizirajo poslovanje, in skupinami, ki

razvijajo programske sisteme.

Razlogi za poslovno modeliranje so sledeči [4, 14]:

● razumeti tekoče probleme v ciljni organizaciji in prepoznati možnosti za izboljšave,

● oceniti vpliv organizacijskih sprememb,

● zagotoviti skupen pogled na organizacijo s strani naročnikov, kupcev, razvijalcev

in drugih deležnikov,

33

● postaviti osnovo za zajemanje zahtev glede bodočega programskega sistema in

● razumeti vpletenost bodočega programskega sistema v organizacijo.

Zajemanje zahtev (angl. Requirements)

Koncept upravljanja zahtev opisuje aktivnosti izvabljanja, dokumentiranja in vzdrževanja

množice zahtev za programski sistem. Nepopolne zahteve in nesodelovanje uporabnikov

sta dva poglavitna vzroka za neuspeh projekta [4]. Disciplina zajemanja zahtev opisuje

aktivnosti, ki zagotavljajo, da so zahteve deležnikov primerno zajete in pretvorjene v

množico izdelkov zahtev. Ti omogočajo postavitev obsega sistema, ki bo zgrajen in

zagotavljajo podrobne zahteve o tem, kaj naj sistem počne. Ogrodje RUP loči štiri tipe

zahtev, in sicer potrebe (angl. needs), funkcionalnosti sistema (angl. system features) –

oboje sodi v dokument vizija, zahteve deležnikov in softverske zahteve. Tipi zahtev se

uporabljajo za izdelavo modela primerov uporabe in dodatne specifikacije, ki opisujeta

funkcionalne, nefunkcionalne in druge zahteve ter predstavljata osnovo za izdelavo

zahtev za implementacijo sistema na nivoju načrtovanja. Notaciji primerov uporabe in

scenarijev, ki se uporabljata v ogrodju RUP za zajemanja funkcionalnih zahtev in hkrati

vodita načrtovanje, implementacijo in testiranje z veliko verjetnostjo zagotavljata izpolnitev

zahtev končnih uporabnikov. Podajata konsistentne in sledljive poti skozi razvoj in razvit

sistem.

Namen discipline zajemanje zahtev je [4, 14]:

● doseči in vzdrževati dogovor z naročniki in drugimi deležniki glede funkcionalnosti

sistema,

● zagotoviti razvijalcem sistema boljše razumevanje zahtev sistema,

● definirati okolje sistema,

● zagotoviti osnovo za načrtovanje tehničnih vsebin iteracij,

● zagotoviti osnovo za oceno stroškov in časa, potrebnega za razvoj sistema, in

● definirati uporabniški vmesnik sistema glede na cilje in potrebe uporabnikov.

Analiza in načrtovanje (angl. Analysis and Design)

Namen discipline analize in načrtovanja je preslikava zahtev v specifikacijo, ki opisuje,

kako implementirati sistem. V ta namen je potrebno zahteve razumeti in jih preslikati v

34

zasnovo sistema z izbiro najboljše strategije implementacije. Disciplina narekuje, da je

potrebno na začetku projekta vzpostaviti robustno arhitekturo, ki omogoča hitro izgradnjo

zasnove sistema, ki jo tudi zlahka razumemo in razvijamo. Tako postavljeno zasnovo je

nato potrebno prilagoditi, da ustreza okolju implementacije, s ciljem doseči ustrezno

učinkovitost, robustnost, skalabilnost in testabilnost. Tudi ovrednotenje, validacija in

načrtovanje arhitekture spadajo v okvir te discipline, kar poudarja njeno vlogo in nakazuje,

da je RUP osnovan na arhitekturi [4].

Implementacija (angl. Implementation)

V disciplini implementacija razvijemo dejansko kodo, integriramo podsisteme in

implementiramo sistem. Testiranje v disciplini implementacija je omejeno le na testiranje

enot posameznih komponent. Integracijsko in sistemsko testiranje je obravnavano v

disciplini testiranje. V praksi sta zato delovna tokova obeh disciplin tesno povezana. V

življenjskem ciklu je poudarek na implementaciji predvsem v fazi konstrukcije kot tudi v

fazah zbiranja informacij in prevzema, kjer se disciplina uporablja za postavitev izvršljive

osnove arhitekture in obravnavo okvar, kot so hibe, odkrite med beta testiranjem sistema.

Namen discipline implementacija je [4, 14]:

● definirati organizacijo kode v obliki implementacijskih podsistemov, organiziranih v

plasteh,

● implementirati elemente načrtovanja v obliki implementacijskih elementov (izvorna

koda, binarne datoteke, izvršljivi programi itd.),

● testirati razvite komponente kot enote in

● integrirati rezultate pozameznih implementatorjev (ali skupin) v izvršljiv sistem.

Testiranje (angl. Test)

Disciplina testiranje podaja napotke o vrednotenju kakovosti programskega produkta in

nudi storitev preostalim disciplinam. Predstavlja iterativni testirni proces, ki je skalabilen,

uporabniško prilagodljiv, načrtovan v duhu fleksibilnosti in osredotočen na učinkovitost.

Iterativno testiranje omogoča zmanjševanje tveganj dovolj zgodaj v razvojnem

življenjskem ciklu, posameznikom ali skupinam omogoča, da odigrajo svoje vloge, kadar

in kjer ima to največ učinka. Nadalje iterativni proces maksimizira učinkovitost po načelu

35

sprotnega prilagajanja pristopa, procesa ali sredstev [4]. V bistvu je disciplina testiranja

zadolžena za iskanje in odkrivanje pomanjkljivosti v produktu, zato temelji na drugačni

filozofiji kot discipline zajemanje zahtev, analize in načrtovanje ter implementacije. Če so

slednje osredotočene na popolnost, konsistentnost in pravilnost, je testiranje usmerjeno

na nepravilnost, nekonsistentnost ali na pomanjkljivosti. Različne raziskave in razprave

navajajo, da zajema testiranje 30 do 50 odstotkov celotnih stroškov razvoja. To nekoliko

preseneča, saj velja načelno prepričanje, da programska oprema običajno ni dovolj dobro

stestirana. To protislovje izvira iz nekaj ključnih problemov, ki zadevajo testiranje. Več v

[16]. V opisu ogrodja je velik poudarek na vizualizaciji in uporabi orodij. Uporaba primernih

orodij, katerih opis se nahaja v ogrodju RUP, je zelo priporočljiva tudi pri testiranju.

Namen discipline testiranja je [4, 14]:

● najti in dokumentirati hibe v kakovosti programske opreme,

● zagotoviti veljavnost predpostavk v specifikaciji analize in načrtovanja skozi

dejansko demonstracijo,

● pogosto obveščati o ugotovljeni kakovosti programske opreme,

● preveriti veljavnost delovanja programskega produkta z načrtom in

● preveriti veljavnost, da so bile zahteve primerno implementirane.

Okolje (angl. Environment)

V preteklosti je veliko IT-organizacij razvilo lastne procesne modele. Sčasoma so te

organizacije razvile tudi šablone izdelkov, ki jih danes uspešno uporabljajo kot formalno

projektno dokumentacijo. Napačno je razmišljanje, da bi uporaba ogrodja RUP v teh

organizacijah pomenila, da obstoječi način dela ni več ustrezen. Ena od idej poslovno

usmerjenega razvoja, ki jo je prevzel tudi RUP, je namreč prilagoditev procesa in

disciplina okolje od procesnega inženirja in projektnega menedžerja zahteva prilagoditev

procesnega ogrodja specifičnim potrebam projekta/organizacije. Prilagajanje procesnega

ogrodja RUP obsega identifikacijo in vključevanje obstoječih najboljših praks organizacije

v prakse in procese, ki jih predlaga ogrodje RUP. Namen discipline okolje je prav v tem,

da nudi pomoč pri izvajanju procesa prilagajanja. Disciplina zagotovi podporno okolje

projektom razvoja programskih sistemov in tako podpira vse ostale discipline. Osredotoča

se na aktivnosti, ki so potrebne za konfiguriranje ustreznega procesa projekta/organizacije

[4].

36

Namen discipline okolje:

● opis aktivnosti, ki so potrebne za konfiguriranje procesa projekta. Definira, kakšne

izboljšave so realne glede na okoliščine projekta (trenutni proces, trenutna orodja,

trenutne izkušnje zaposlenih in njihova zmožnost spreminjanja, tekoči problemi in cilji

možnih izboljšav).

Vodenje projektov (angl. Project Management)

Vodenje projektov je v ogrodju podporna disciplina in ne zajema celotnega spektra znanja

s področja projektnega vodenja, ki je podano v različnih standardih kot npr. Projekt

Management Body of Knowledge (PMBK), ki ga je izdal Project Management Institute.

Tako procesni model na primer ne naslavlja upravljanja s človeškimi viri (zaposlovanje,

usposabljanje, zunanje svetovanje), upravljanja proračunov (opredelitev, dodelitev) in

upravljanja pogodb z dobavitelji in strankami. Disciplina se osredotoča na obladovanje

tveganja, načrtovanja iterativnega projekta in spremljanja napredovanja iterativnega

projekta, ki predstavljajo specifične vidike iterativnega razvojnega procesa. PMBK

opredeli procesno vodenje kot uporabo znanja, veščin, tehnik in orodij v aktivnostih

projekta za izpolnitev njegovih (projektnih) zahtev. Projektno vodenje realiziramo z

uporabo in integracijo procesov projektnega vodenja. Ti so: zagon, planiranje, izvajanje,

spremljanje, kontroliranje ter končanje. Uravnoteženje konkurenčnih (nasprotujočih si)

ciljev, obvladovanje tveganj in premagovanje omejitev so principi projektnega vodenja, ki

so zajeti v tej disciplini. Uporabljajo se z namenom oz. nalogo izdelave produkta, ki

ustreza potrebam naročnikov in končnih uporabnikov. O težavnosti te naloge govori

dejstvo, da je le malo projektov popolnoma uspešnih. Cilj discipline je zato podati takšne

napotke za vodenje projektov, da je to nalogo mogoče izpolniti čim bolj enostavno. To ne

zagotavlja uspeha, vendar omogoča vodjem RUP projektov, da vodijo projekte na način,

ki bo močno povečal verjetnost razvoja takšne programske opreme, ki bo uspešno služila

svojemu namenu.

Namen discipline vodenja projektov je [4, 14]:

● zagotoviti okvir za vodenje projektov razvoja programske opreme,

● podati praktične smernice za planiranje, kadrovanje, izvajanje in spremljanje

projektov ter

37

● zagotoviti okvir za obvladovanje tveganj.

Upravljanje konfiguracij in sprememb (angl. Configuration and Change Management)

Procesno ogrodje RUP izčrpno opisuje sistem upravljanja konfiguracije, ki pokriva vse

vidike upravljanja konfiguracije (angl. configuration management). Osnovni namen

sistema upravljanja konfiguracije je nadzor nad številnimi izdelki, ki jih izdeluje veliko

posameznikov v skupnem projektu. Nadzor pomaga preprečevati zmedo v razvojnem

projektu, ki jo povzročajo sočasna ažuriranja, omejena obveščanja in več verzij. Sistem

upravljanja konfiguracije zagotavlja ustrezno podporo razvojnim opravilom v življenjskem

ciklu projekta, integriteto proizvoda, popolnost in pravilnost konfiguriranega proizvoda,

stabilno okolje, v katerem se razvija proizvod, in učinkovito obvladovanje sprememb.

Poleg tega sistem upravljanja konfiguracije vodi podrobne podatke o razvojnem procesu

(npr. beleži kdo, kdaj in zakaj je ustvaril določeno verzijo). Sistem upravljanja konfiguracije

IT-podjetja se uporablja v celotnem življenjskem ciklu produkta, od zbiranja informacij do

dobave. Kot repozitorij dobrin (angl. asset) organizacije sistem za upravljanje konfiguracije

zajema sedanje in pretekle verzije izvornih datotek izdelkov zahtev, načrtovanja in

implementacije, ki opredeljujejo določeno verzijo sistema ali njegovo komponento.

Struktura direktorija produkta (angl. product directory structure) vključuje vse izdelke,

potrebne za implementacijo produkta. Na ta način je disciplina povezana s preostalimi

disciplinami, saj nudi repozitorij njihovim izdelkom. Sistem upravljanja konfiguracije

zagotavlja tudi stopnjo nadzora, ki je povezana z vsakim izdelkom glede na njegovo

stopnjo zrelosti. Tako se avtorizacija izdelkov z njihovo zrelostjo pomika od razvijalcev k

integratorjem podsistemov ali sistema, do vodje projekta in vse do strank. Sistem prav

tako omogoča razvijalcem izvajanje opravil, povezanih z upravljanjem konfiguracije, z

minimalnimi posegi v razvojni proces. Sistem upravljanja je v podporo tudi projektnim

vodjem pri nadzoru nad projektom, saj jim zagotavlja različna poročila o statusu in

meritvah, povezanih s konfiguracijo in spremembami.

Namen discipline upravljanje konfiguracije in sprememb je:

● nadzor sprememb in ohranjanje integritete izdelkov.

38

Dobava (angl. Deployment)

Ta disciplina opisuje aktivnosti, ki so povezane z beta testiranjem in dobavo namestljive

programske opreme. Aktivnosti dobave kulminirajo v fazi prevzema in predstavljajo

vrhunec naporov, povezanih z razvojem. Uspešnost dobave in seveda celokupno

uspešnost projekta določa pripravljenost uporabnikov za uporabo nove programske

opreme. Cilj aktivnosti discipline dobave je zagotoviti nemoten prehod uporabnikov na nov

sistem, ki so ga zmožni tudi samostojno uporabljati. Namestitev proizvoda lahko izvede

prodajalec (v primeru kompleksnih in porazdeljenih sistemov) ali uporabnik sam (v

primeru komercialne rešitve ali rešitve, dobavljene po internetu).

Disciplina opisuje tri načine dobave produkta: namestitev po meri (angl. custom install),

ponudba komercialne programske opreme za neznanega uporabnika in dostop do

programske opreme po internetu. V vseh pristopih se najprej izvede testiranje

sprejemljivosti produkta pri prodajalcu (razvojno okolje), nato sledi beta testiranje in izdaja

končnega proizvoda strankam.

Namen discipline dobave je:

● obvladovanje aktivnosti, ki zagotovijo, da je razvit proizvod na voljo končnim

uporabnikom. Te aktivnosti so: dobava produkta, prevzemno testiranje z namestitvijo

(angl. installation) v razvojnem in ciljnem okolju, beta testiranje, oblikovanje

podpornega gradiva za končnega uporabnika, oblikovanje dokumentacije za

izobraževanje in izdaja strankam preko spletnih strani itd. Načini, po katerih se te

aktivnosti izvajajo v IT-industriji, se zelo razlikujejo in so odvisni od velikosti projektov,

načina dobave in poslovnega konteksta.

Vloge ter izdelki opisanih disciplin so predstavljeni v tabeli 4.

39

Tabela 4: Glavne in obrobne vloge ter izdelki disciplin ogrodja RUP [4, 14, 16]

DISCIPLINE

GLAVNE VLOGE

OBROBNE VLOGE

GLAVNI IZDELKI

Poslovno modeliranje

analitik poslovnega procesa, poslovni načrtovalec, poslovni arhitekt

tehnični pregledovalec

dokument poslovne arhitekture, model poslovnih primerov uporabe, model poslovnega načrtovanja, ocena ciljne organizacije

Zajemanje zahtev

sistemski analitik, popisovalec zahtev

arhitekt programske opreme, tehnični pregledovalec

vizija, slovar, načrt upravljanja, softverske zahteve, specifikacija zahtev, zahteve deležnikov, zgodborisi, dodatne specifikacije, model primerov uporabe, zahtev

Analiza in načrtovanje

arhitekt programske opreme, sistemski analitik, načrtovalec, načrtovalec uporabniškega vmesnika, načrtovalec podatkovne baze

načrtovalec podatkovnega modela, tehnični pregledovalec, načrtovalec testiranja

model analize, model načrtovanja, dokaz koncepta arhitekture, model podatkov, referenčna arhitektura, dokument arhitekture programske opreme, načrt strukture in navigacije uporabniškega vmesnika

Implemen- tacija

implementator, povezovalec, arhitekt programske opreme

tehnični pregledovalec

implementacijski elementi, podsistem implementacije, načrt integracije gradenj

Testiranje

vodja testiranja, analitik testiranja, načrtovalec testiranja, preskuševalec

načrtovalec, implementator, procesni inženir

testna strategija, testirni načrt, seznam testnih idej, konfiguracija testirnega okolja, testni primer, testni podatki, testna skripta, testna garnitura, testni dnevnik, model analize obremenitve, povzetek ocenjevanja testiranja, rezultati testiranja, arhitektura sistema avtomatskega testiranja, specifikacija testirnega vmesnika

Upravljanje konfiguracij in sprememb

upravitelj konfiguracije, upravitelj nadzora sprememb

povezovalec, vsaka vloga, vodja projekta, analitik testiranja

zahteva za spremembo, plan upravljanja konfiguracije, repozitorij projekta, delovni prostor

Vodenje projektov

vodja projekta, pregledovalec upravljanja

pregledovalec, usklajevalec pregledov

poslovni primer, plan razvoja programske opreme, plan iteracij, zapisnik pregleda, seznam tveganj, seznam spornih zadev, ocenitev statusa, delovni nalog, plan namestitve

Okolje

procesni inženir, sistemski administrator, strokovnjak za orodja

analitik poslovnega procesa, sistemski analitik, načrtovalec uporabniškega vmesnika, arhitekt programske opreme, tehnični pisar

proces razvoja, razvojni primer, smernice prilagojene projektu, predloge prilagojene projektu, razvojna infrastruktura, ocenitev organizacije razvoja, navodila za izdelavo priročnikov

40

Dobava

vodja dobave, upravljalec namestitve, pripravljalec tečaja, grafik, upravitelj konfiguracije, tehnični pisar

implementator, preskuševalec, sistemski administrator, analitik testiranja

model dobave, enota dobave, proizvod, priročnik za uporabnike

41

6 OGRODJE MSF

V obdobju zadnjih desetih let je področje informatike in informacijske tehnologije

podvrženo dramatičnim spremembam. Te zadevajo tako področje uporabe kot tudi hitrost

sprememb. Podjetja informacijsko tehnologijo zaznavajo kot ključni dejavnik bodočega

uspeha in ne zgolj kot potreben režijski strošek. Potrebe po informacijah v poslovanju so

gonilna sila razvoja IT-rešitev. Uspešna implementacija teh rešitev pa ni odvisna le od

tehnologij, ampak tudi od ljudi in procesov.

Dandanes organizacije iščejo procese in potrjene prakse z namenom maksimiranja

naložb v IT. Microsoft je v ta namen razvil ogrodje MSF, ki temelji na potrjenih najboljših

praksah, ki so rezultat njegovega nekaj desetletnega razvoja programske opreme in

infrastrukture. Skozi modela, discipline in prakse ogrodje MSF naslavlja vloge,

odgovornosti in procese znotraj življenjskega cikla projekta. Fleksibilnost ogrodja

omogoča podjetjem in organizacijam možnost prilagajanja lastnim potrebam. MSF 4.0 je

uporaben, fleksibilen in preverjen pristop k razvoju IT-rešitev [7]. Uspešno se uporablja v

številnih projektih z različno kompleksnostjo in različnimi okolji. Skozi dolgo obdobje

izboljšav in razvoja ogrodje podaja smernice ne samo kako definirati, načrtovati, graditi,

stabilizirati in dobaviti informacijske rešitve, ampak tudi kako organizirati, pripraviti in

upravljati skupine v dinamičnem okolju izdelave informacijskih rešitev. MSF je povezan z

ogrodjem MOF (Microsoft Operation Framework), ki zagotavlja optimalno delovanje

rešitev. Skupno oblikujeta celotni življenjski cikel rešitev, kot prikazuje slika 8.

Slika 8: Življenjski cikel tehnoloških rešitev podjetja Microsoft [7]

42

6.1 Zgodovina

Ogrodje MSF je bilo doslej posodobljeno štirikrat. Tako kot vse prejšnje verzije je tudi

najnovejša odgovor na spreminjajoče se okolje ter rezultat globljega in širšega

razumevanja kako projektne skupine razvijajo IT-rešitve. Prva verzija je bila predstavljena

leta 1994 kot ohlapna zbirka najboljših praks, ki so bile rezultat prizadevanj znotraj

Microsoftovih razvojnih skupin in angažiranj pri izvajanju svetovalnih storitev. Od takrat se

ogrodje nenehno razvija, saj temelji na uporabi uspešnih, preizkušenih najboljših praksah

Microsoftovih razvijalcev, konzultantov, IT-skupin, partnerjev in strank. Slika 9 prikazuje

zgodovinsko evolucijo razvoja ogrodja MSF.

1994 1997 1999 2002 2005/06- 2013

MSF 1.0

MSF 2.0

uvedba discipline razvoja

rešitev

MSF 2.5 vpeljava principov za:

razvoj aplikacij

načrtovanje komponent

uvedbo infrastrukture

MSF 3.0

združena skupinski in procesni model

spremembe v disciplini upravljanja s tveganji

povezava med MSF in MOF

MSF 4.0

spremembe v skupinskem in procesnem modelu

inačice ogrodja

Slika 9: Evolucija ogrodja MSF

MSF je strukturiran kot fleksibilno ogrodje in predstavlja osnovo za gradnjo metodologij

oz. inačic ogrodja, ki skupaj oblikujejo družino MSF. Ogrodje MSF 4.0 je v številnih

pogledih podobno ogrodju MSF 3.0, vendar hkrati med njima obstaja velika razlika, saj

prvo zagotavlja tri metodologije oz. troje predpisanih navodil k razvoju informacijskih

rešitev, in sicer MSF for Agile Software Development (slika 10), MSF for CMMI Process

Improvement in Microsoft Visual Studio Scrum.

43

Slika 10: MSF for Agile Software Development [27]

Kot je razvidno iz slike 11, inačice v družini infrastruktura še niso razvite. Pomembno je

opozoriti, da lahko podjetja na osnovi ogrodja definirajo lastne inačice – metodologije [7].

Pomembne posodobitve naslavljajo tudi oba modela ogrodja – skupinski in obvladovalni.

Slika 11: MSF družinsko drevo [7]

44

6.2 Struktura ogrodja MSF

Osnovna struktura ogrodja je sestavljena iz osmih značilnosti (principov) in dveh modelov

(model skupine, model obvladovanja) ter treh disciplin (upravljanje tveganj, upravljanje

usposobljenosti in projektnega vodenja) [5]. Čeprav so bile te komponente načrtovane z

namenom skupnega delovanja, se lahko uporabljajo tudi samostojno. Tako lahko na

primer organizacije uporabljajo svojo lastno projektno metodologijo, vendar uvedejo osem

ključnih principov, ali pa uporabljajo svojo množico projektnih vlog in hkrati prevzamejo

šest poti procesnega ogrodja. Osnovno strukturo dopolnjujejo usmeritve, uveljavljene

prakse in priporočila, ki povečujejo uporabnost ter prilagodjivost ogrodja pri projektih

različnih velikosti in kompleksnosti.

6.3 Značilnosti ogrodja MSF

Osnovne značilnosti (ideje), ki bodo opisane v tem podpoglavju, vključujejo celotno

filozofijo visoko učinkovitih razvojnih skupin. Vsaka značilnost je uporabna sama zase,

vendar skupna uporaba vzpostavi dobro osnovo, ki omogoča ogrodju dobro delovanje v

projektih različnih velikosti, kompleksnosti in tipov.

Gojiti odprto komunikacijo

Za uspešno in optimalno opravljanje dela potrebujejo posamezniki in skupine primerne

informacije, ki so zmeraj na voljo in aktivno deljene. Brez odprte komunikacije, ki omogoča

širok dostop do teh informacij, člani skupine ne morejo učinkovito opravljati svojega dela

ali sprejemati dobrih odločitev. Z naraščanjem kompleksnosti in velikosti projektov se

vedno bolj odraža tudi potreba po vzpostavitvi odprte komunikacije [6]. Prost pretok

informacij ne le zmanjšuje možnosti za nesporazume in nepotrebno delo, temveč tudi

zagotavlja, da lahko vsi člani prispevajo k zmanjševanju negotovosti projekta, tako da

aktivno delijo informacije, ki pripadajo njihovim področjem dela.

45

Delati v smeri skupne vizije

Postavitev skupne vizije zagotavlja agilnost, saj lahko člani skupine hitro sprejemajo

premišljene odločitve v okviru uresničevanja vizije. Skupna vizija prav tako pomaga

članom skupine zapolniti vrzeli v zahtevah, če se te pojavijo. Včasih, ko skupina obstane

na mestu, lahko vizija zagotovi motivacijo in zaupanje v prihodnost. Skupna vizija

zagotavlja jasne in kvantificirane cilje ter ne podaja opisa, kako naj bodo ti izpolnjeni. Če

vsi udeleženci v projektu razumejo in delujejo v skladu s skupno vizijo, potem usklajujejo

svoje odločitve in prioritete s širšim namenom, ki ga predstavlja vizija. Brez skupne vizije

imajo lahko člani skupine in ostali deležniki nasprotujoče si poglede glede usmeritev, ciljev

in namena projekta, kar pa jim onemogoča usklajeno delovanje.

Dati pooblastila članom skupine

Pooblaščanje oz. opolnomočenje (angl. empowerment) članov skupine pomeni stopnjo

zaupanja, da bodo vsi člani skupine izpolnili svoje obveznosti. Zaupanje si morajo člani

skupine pridobiti z doseganjem zastavljenih ciljev, zanesljivostjo, znanjem itd.

Opolnomočeni člani skupine se počutijo odgovorni do samih sebe in do ostalih članov

glede doseganja ciljev in izdelave izdelkov projekta. Če se člani skupine počutijo

opolnomočeni, odgovorni za celotno rešitev in imajo skupno vizijo, obstaja velika

verjetnost sprejemanja dobrih odločitev na nivoju projekta [7]. Tudi manj opolnomočene

skupine lahko uspešno opravljajo svoje delo v pogojih, ki narekujejo bolj formalne in

ponovljive procese razvoja, vendar pa bi tudi tukaj opolnomočenje članov skupine

povečalo verjetnost uspešne izdelave IT-rešitev [6]. Manj delitve moči namreč zmanjšuje

kreativnost, znižuje moralo in tako spodkopava zmožnost ustvarjanja visoko učinkovitih

skupin. Prav tako organizacije, ki kritizirajo in hvalijo posamezne člane skupine, ne

ustvarjajo temeljev za opolnomočenje.

Vzpostaviti jasno polaganje računov in deljeno odgovornost

Vzpostavitev jasnega polaganja računov oz. osebne odgovornosti (angl. accountability) za

odločitve in deljene odgovornosti (angl. shared responsibility) za posamezne vidike ali

celotni projekt preprečuje podvajanje dela in hkrati zagotavlja izdelavo vseh izdelkov, ki so

potrebni za uspeh projekta.

46

Ostati agilen, pričakovati spremembe in prilagajanje

Spremembe so stalnica tudi v projektih razvoja tehnoloških rešitev. Agilen način ravnanja

s spremembami omogoča, da so posledice sprememb majhne. Ostati agilen pomeni

pripravljenost organizacije na spremembe in zmožnost prilagajanja le-tem. Eden od

najboljših načinov ravnanja s spremembami je dobro razumevanje prioritet omejitev

projekta in postavitev procesa, ki hitro preuči in določi kaj storiti glede sprememb.

Investirati v kakovost

IT-organizacije, ki uspešno izvajajo programe upravljanja kakovosti, vključujejo v svojo

kulturo tudi kakovost. Te organizacije poudarjajo potrebo po neprenehnem vlaganju v

kakovost, ker se pričakovanja v zvezi z njo praviloma s časom povečujejo. Kakovost je

opredeljena na več načinov. Preprosto jo je mogoče razumeti kot neposreden odraz

stabilnosti rešitve, kar je opravljeno ali narejeno s konsistentnim procesom ali kot

zapletena uskladitev dela, stroškov in funkcionalnosti. Kakovost mora biti kvantificirana,

definirana in načrtovana [7]. Ne zgodi se naključno. Zahteva vložek časa in virov. Gre za

mešanico ukrepov za preprečevanje in preverjanje. Investicija v kakovost je vložek v ljudi,

procese in orodja. Vsaka organizacija mora razumeti, kaj je pravi nivo kakovosti za vse

vidike rešitve, od komponent programske opreme do uporabniških priročnikov.

Razmišljanje o ustreznih nivojih kakovosti spodbuja ekipe in posameznike k razvoju

usmeritve (angl. mindset), katere namen je izboljševati kakovost.

Učiti se iz vseh izkušenj

Stopnja uspešnosti tehnoloških projektov se je v zadnjih dvanajstih letih le znatno

izboljšala. Glede na to, da glavni vzroki neuspehov ostajajo isti, se zdi, da se IT-

organizacije ne učijo dovolj na svojih napakah. Treba je razumeti in upoštevati, da se

učenje dogaja na vseh nivojih (individualnem, projektnem in organizacijskem). Aktivnosti

zajemanja in izmenjave tehničnih in netehničnih izkušenj so ključnega pomena za

nenehno izboljševanje in kontinuiran uspeh, ker npr. omogočajo članom skupine izkoristiti

pozitivne in negativne izkušnje ostalih, pomagajo članom skupine ponoviti uspehe in se

izogibati napakam, omogočajo učenje z uporabo tehnik pregleda in retrospektive.

Zajemanje znanja, pridobljenega na projektu, ki postane dostopno za uporabo, zmanjšuje

negotovost pri naslednjih projektih v primeru nepopolnih informacij.

47

Biti partner s strankami

Uspeh je rezultat skupinskega dela. To pomeni, da stranke tesno sodelujejo z razvojno

skupino z namenom izdelave rešitve, ki zadovoljuje njihova pričakovanja. Partnerstvo s

stranko je obojestransko koristno, saj pomaga zmanjšati negotovost, skrajšati čas,

potreben za odgovore glede zahtev, ter preko rednih stikov izboljšati razumevanje

predlogov, ki se tičejo vrednosti rešitve.

Razvijati vrednost inkrementalno

Obstajata dva vidika inkrementalnega razvoja vrednosti. Prvi vidik je zagotoviti, da ima to,

kar se razvija, optimalno vrednost za deležnike (sodelujoče). Drugi vidik obsega določanje

optimalnih inkrementov razvoja vrednosti (frekvenca razvoja).

6.4 Vloge ogrodja MSF

Zagovorniške skupine (angl. advocacy groups) oz. vloge so v ogrodju MSF opisane v

skupinskem modelu (angl. team model). Skupinski model temelji na konceptu

zagovorništva (angl. advocacy), kjer je vsak član projektne skupine zagovornik svojih

ciljev kakovosti (angl. quality goals), svojih deležnikov (angl. constituent) in funkcijske

enote v organizaciji, ki jo zastopa (npr. marketinški oddelek) [7]. Vloge v modelu niso opisi

delovnih mest in ne določajo organizacijske sheme podjetja ali oddelka. Število ljudi v

posamezni vlogi je lahko variabilno, lahko pa oseba zaseda tudi več vlog hkrati. Vloge so

sestavljene iz posameznih funkcijskih enot (angl. functional areas), ki zagotavljajo

združevanje podobnih odgovornosti in aktivnosti ter tako omogočajo boljšo organizacijo

dela v večjih projektnih skupinah (npr. vloga arhitekta se nadomesti z vlogama arhitekt

rešitve in tehnični arhitekt). Slika 12 prikazuje povezave med sedmimi zagovorniškimi

skupinami ogrodja in funkcijskimi območji znotraj njih.

48

Slika 12: MSF model skupine – prirejeno po [7]

Iz slike 12 je razvidno, da model skupine ni hierarhična struktura, saj temelji na usmeritvi

enako pomembnih vlog (angl. team of pears), ki sodelujejo pri upravljanju in uspešnem

razvoju rešitve. Pomembne odločitve v skupini se sprejemajo s skupnim konsenzom med

vsemi vlogami, ki nastopajo v projektu. Vsaka skupina se mora sama organizirati na

način, ki ji omogoča, da na osnovi danih zavez (angl. commitment) svojih članov najbolje

razvija programske sisteme in rešitve. Skupinski model temelji na načelu, da je projekt

uspešen, ko so izpolnjeni vsi cilji kakovosti (tabela 5) vseh sedmih zagovorniških skupin

oz. vlog. Cilji kakovosti vodijo in definirajo skupinski model ogrodja [7].

49

Tabela 5: Cilji kakovosti [7]

ZAGOVORNIŠKA SKUPINA

CILJI KAKOVOSTI

Vodenje produkta zadovoljni deležniki definiranje rešitve v okviru omejitev projekta

Vodenje programa koordinacija identifikacij in optimizacij omejitev projekta izdelava rešitve v okviru omejitev projekta

Arhitektura načrtovanje rešitve v okviru omejitev projekta

Razvoj izgradnja rešitve na podlagi specifikacij Testiranje potrditi, da vsi vidiki rešitve izpolnjujejo ali presegajo

opredeljene stopnje kakovosti Zadovoljstvo uporabnikov maksimiranje uporabnosti rešitve

izboljšanje usposobljenosti in učinkovitosti uporabnikov Izdaja/Obratovanje nemotena dobava in prehod v obratovanje

Pri uporabi modela je zato pomembno, da ima vsaka skupina svojega zagovornika.

Čeprav je res, da je celotna projektna skupina odgovorna za uspeh projekta, so v modelu

z namenom prevzemanja osebne odgovornosti in osredotočanja cilji kakovosti pridruženi

posameznim zagovorniškim skupinam. Vsaka zagovorniška skupina tudi zagovarja

posamezne vidike interesov svojih deležnikov. Skupno tudi ti vidiki določajo potrebne

kontrole in uravnoteženja, ki so potrebni za izdelavo prave rešitve. V nadaljevanju bomo

opisali sedem zagovorniških skupin – vlog ogrodja MSF.

Vodenje produkta (angl. Product management) – Produktni vodja

Produktni vodja zagotavlja, da so vsa pričakovanja deležnikov razumljena in upravljana

ves čas trajanja projekta. Dodatno skrbi, da je stranka, ki je projekt finančno podprla,

zadovoljna s potekom in izidom projekta. Za učinkovito delo je potrebno razumeti,

skomunicirati in zagotoviti uspeh z vidika deležnikov, zato je skupina zelo komunikacijsko

naravnana. Skupina poseduje in vodi definiranje zahtev in eno ali več množic

funkcionalnosti (angl. feature set), pomaga razumeti uporabniške profile in način uporabe

rešitve. Med projektom postavlja in prilagaja vizijo rešitve skupaj z eno ali več strankami.

Vodenje programa (angl. Program management) – Programski vodja

Skupina vodenje programa vodi razvoj rešitve tako, da upošteva zgodovino, upravlja s

sedanjostjo in napoveduje prihodnost. Skupina upravlja s tveganji in nenehno izvaja

uravnoteženje in optimiziranje znanih omejitev projekta.

50

Arhitektura (angl. Architecture) - Arhitekt

Arhitekt oblikuje načrt(e) rešitve in procese načrtovanja. Zagotavlja nujno potrebno

povezavo med poslovnim delom rešitve, ki ga predstavljata upravljanje produkta in

konceptualni načrti, ter med tehnološkim delom rešitve, ki ga predstavljata razvoj in

podrobni načrti implementacije. Arhitekti delujejo kot skrbniki vsebine v funkcionalnih

specifikacijah. Skupina med drugim obravnava vse zahteve, omejitve in pričakovanja, ki

vplivajo na rešitev. Vse te zahteve skupina pretvori v načrt(e) rešitve.

Razvoj (angl. Developer) - Razvijalec

Skupina se osredotoča na izgradnjo rešitve skladno z arhitekturo rešitve in arhitekturo

implementacije, ki skupaj s specifikacijo funkcionalnosti tvorijo specifikacijo rešitve.

Skupina definira nizkonivojske podrobnosti rešitve, načrtuje implementacije značilnosti,

izpopolni ocene glede izgradnje značilnosti, zgradi rešitev in preveri, če je ta skladna s

specifikacijami.

Testiranje (angl. Tester) - Preskuševalec

Vse rešitve imajo napake, zato skupina vodi pogovore med skupino in deležniki, da ti

dosežejo soglasje o pomembnih napakah. To so napake, ki lahko ustavijo izdajo rešitve.

Nato skupina meri in spremlja kakovost rešitve tako dolgo, dokler rešitev ne doseže

zahtevanega nivoja kakovosti in je pripravljena za izdajo. Skupina preverja delovanje

rešitve z vidika deležnikov.

Zadovoljstvo uporabnikov (angl. User Experience) – Zadovoljstvo uporabnikov

Odgovornost skupine je zagotoviti čim bolj učinkovito rešitev za uporabnike in ustrezno

pripravljenost uporabnikov za učinkovito uporabo rešitve. Še preden se skupina formira,

ključni posamezniki skupaj s sponzorjem projekta opredelijo problem oz. priložnost in

definirajo začetno vizijo rešitve.

Izdaja/Obratovanje (angl. Release/Operations) – Izdaja/Obratovanje

Disciplina zagotavlja tekočo izdelavo in dobavo rešitve. Čeprav življenjski cikel na sliki 8

51

ponazarja dobavo izdaje (angl. release) verzije rešitve k skupini, ki skrbi za upravljanje

obratovanja informacijske rešitve v ogrodju MOF, obstajajo v primeru komercialne izdaje

še druge destinacije in komunikacijski kanali. Skupina v celotnem življenjskem ciklu

sodeluje pri izgradnji produkcijskega okolja s skupino v ogrodju MOF, ki je odgovorna za

upravljanje obratovanja rešitve, saj od nje sprejema zahteve glede obratovanja in/ali

omejitev, ki jih pregleda in posreduje v premislek projektni skupini.

6.5 Poti ogrodja MSF

Model obvladovanja (angl. governance model) je strukturiran na način, da pomaga skupini

pri hitrem doseganju skupnega konsenza glede uresničitve različnih vidikov rešitve [7].

Model je prilagodljiva komponenta ogrodja MSF in se uspešno uporablja pri izboljšanju

nadzora projekta, zmanjševanju tveganj, izboljšanju kakovosti rešitev in povečevanju

hitrosti izdelave. Od IT-organizacij se pričakuje, da model prilagodijo potrebam svojih

poslovnih procesov in obstoječim pristopom razvoja. Model omogoča spremembe v

projektnih zahtevah s pomočjo iteracij preko kratkih razvojnih ciklov in inkrementalnih

verzij rešitve. Model obvladovanja, kot ga prikazuje slika 13, sestavljajo poti realizacije

(angl. enactment tracks), ki so namenjene definiranju, izgradnji in dobavi IT-rešitev, ki

izpoljnjujejo potrebe in pričakovanja deležnikov ter pot obvladovanja (angl. project

governance), ki se osredotoča na optimiziranje procesa razvoja in na učinkovito ter

uspešno uporabo projektnih virov [7]. Poti sestavljajo prekrivajoče in usklajene skupine

določenih aktivnosti, katerih cilj je izdelava izdelkov posameznih poti. Vsaka pot ima svoj

cilj (npr. cilj poti stabilizacija je zagotoviti rešitev, ki je v skladu s pričakovanji) in

predstavlja nov korak ter osredotočenje v projektu. Poti uporabljajo točke sinhronizacije in

pregledov, imenovane kontrolne točke (angl. checkpoint). MSF opiše šest glavnih in več

vmesnih kontrolnih točk (angl. major and interim checkpoints). Več v podpoglavju 7.3.

Kontrolne točke so namenjene za [7]:

● pomoč pri sinhronizaciji delovnih paketov,

● zagotavljanje zunanje vidljivosti napredka in kakovosti,

● omogočanje izboljšav med izvajanjem projekta,

● osredotočanje pri pregledih na cilje in izdelke in

● zagotavljanje odobritev za nadaljnje delo.

52

Slika 13: Model obvladovanja – prirejeno po [7]

V nadaljevanju bomo opisali posamezne poti razvoja.

Pot vzpostavitev projekta (angl. Envision Track)

Pot vzpostavitev projekta oz. definiranje rešitve naslavlja poenotenje projektne skupine

glede skupne vizije, ki je osnovna zahteva za uspeh vsakega projekta. Skupina mora imeti

jasno zapisano vizijo o tem, kaj želi doseči in to na način, ki motivira celotno skupino,

stranko in ostale. Definiranje visokonivojskih ciljev in omejitev projekta na tej poti

predstavlja zgodnjo obliko planiranja in osnovo za izvedbo bolj podrobnega planiranja na

naslednji poti. Primarni aktivnosti, ki se izvajata na poti, sta formiranje projektne skupine in

izdelava dokumenta vizije in obsega projekta. Glavni izdelki poti so dokument

vizije/obsega, dokument projektne strukture ter dokument začetne ocene tveganj.

Pot planiranja (angl. Plan Track)

Pot planiranja podaja odgovore na vprašanja kaj, kako in kdaj se naj zgradi in katera

podporna okolja so za to potrebna. Skupina na podlagi izdelkov prejšnje faze definira

53

zahteve, ki v celoti opišejo rešitev in jih dokumentira v funkcionalni specifikaciji, razvije

podrobne načrte in arhitekture ter pripravi delovne plane, ocene stroškov in urnike za

različne izdelke te poti. Prav tako definira in zgradi potrebna podporna okolja za razvoj

rešitve. Učinkovito izvedeno planiranje zmanjša tveganje, izboljša kakovost in prepozna

vrzeli v razmišljanju. Glavni izdelki poti so funkcionalna specifikacija, glavni časovni

razpored za projekt ter glavni projektni plan.

Pot izgradnje (angl. Build Track)

Pot izgradnje je namenjena izdelavi vseh vidikov rešitve na podlagi izdelkov predhodne

poti (načrti, plani, urniki, zahteve itd.). Na tej poti se razvijejo lastnosti, zmožnosti in

komponente rešitve (do nivoja, ki zahteva le še stabilizacijo) in drugi elementi rešitve, npr.

podporna infrastruktura, dokumentacija in navodila za obratovanje. Testiranje na tej poti

bodisi vodi ali podpira konstruiranje in obsega preverjanja skladnosti s specifikacijami,

odkrivanje programskih napak ter identifikacijo nepričakovanega obnašanja. Ocena

uporabnosti, zagotovitev, da rešitev izpolnjuje pričakovanja deležnikov in druge vrste

testiranj, se izvajajo na naslednji poti, na poti stabilizacije. Izdelke poti izgradnje podaja

tabela 6.

Tabela 6: Glavni izdelki poti izgradnje – klasificirani po vlogah [7]

VLOGA

IZDELKI

Produktni vodja marketinški materiali, načrt komunikacije s končnimi uporabniki

Programski vodja ažuriran glavni plan, dokument časovnega razporeda, dokument

tveganj, zamrznjene funkcionalne specifikacije

Arhitekt

izdelane zasnove

Razvijalec izvorna in izvršljiva koda, slike in dokumenti izgradnje, elementi podpore učinkovitosti

Preskuševalec testne specifikacije, testni primeri s pričakovanimi rezultati, testne metrike, testne skripte, testni podatki, testni pripomočki

Zadovoljstvo uporabnikov

uporabniški referenčni materiali, grafični elementi uporabniškega vmesnika, izobraževanje končnih uporabnikov, testni scenariji uporabnosti

Izdaja/Obratovanje procesi in postopki dobave, namestitvene skripte in nastavitve konfiguracije za dobavo, navodila za obratovanje in standardni postopki za obratovanje, postopki za pomoč in podporo, baza znanja, izobraževanje podpornega osebja, dokumentacija za podporo

54

Pot stabilizacije (angl. Stabilize Track)

Potem ko so elementi rešitve zgrajeni po specifikacijah, stabilizacija zagotovi dodatni nivo

ocenjevanja (npr. funkcijsko testiranje, testiranje uporabnosti) in posodabljanja z

namenom izpolnitve kriterijev za izdajo (angl. release criteria) ter uspešne dobave in

obratovanja integrirane rešitve v njenem ciljnem okolju, saj se na poti stabilizacije prav

tako izvaja ocenjevanje rešitve v dejanskem produkcijskem okolju oz. takšnem, ki ga

posnema (npr. sistemsko testiranje, pilotsko testiranje). Pot tako zagotovi rešitev, ki je

uporabna za uporabnike in izpolnjuje potrebe in pričakovanja deležnikov. Ogrodje opiše

tudi dva statistična indikatorja, in sicer konvergenco napak in točko brez napak, ki

pomagata skupini predvideti, kdaj bo rešitev dosegla stopnjo stabilnosti. Ključni izdelki poti

stabilizacije so povezane komponente rešitve, skripti in namestitvena dokumentacija,

materiali za pomoč, izobraževanje in komuniciranje s končnimi uporabniki, dokumentacija

za izvajanje, testna poročila, poročila metrik kakovosti in obvestila za izdajo.

Pot dobave (angl. Deployment Track)

Namen dobave je uspešna integracija rešitve v produkcijski sistem v okviru načrtovanega

okolja/okolij ter prenos odgovornosti za dobavo oz. namestitev rešitve od projektne

skupine na skupini za izvajanje in podporo v ogrodju MOF. Preden se dobava rešitve v

ciljno okolje/okolja lahko začne, je potrebno zagotoviti ustrezne vire, ki obsegajo ljudi,

opremo, prostore in naprave, orodja in skripte ter preveriti načrt in pristope dobave. Enako

kot na drugih poteh je tudi dobavo rešitev mogoče realizirati na mnogo različnih načinov,

zato ogrodje MSF tudi pot dobave opiše z aktivnostmi in točkami preverjanj, ki so skupne

različnim pristopom. Aktivnosti, ki ju zasledimo na poti, sta namestitev v produkcijsko

okolje, ki je opisana z življenjskim ciklom namestitve po enotah, in prenos rešitve k

izvajanju in podpori. Glavna kontrolna točka na tej poti je dobava zaključena. Osnovna

tehnologija dobavljena, dobava po enotah zaključena in dobava stabilna pa predstavljajo

vmesne kontrolne točke. Na poti se izdelajo glavni izdelki, kot so informacijski sistemi za

izvajanje in podporo, pregledani procesi in procedure, materiali za usposabljanje končnih

uporabnikov in administratorjev, dokumentirane konfiguracije in repozitorij, ki obsega

dokončne verzije dokumentov, baze znanj, konfiguracije, skripte in kodo.

55

Pot obvladovanja (angl. Governance Track)

Ogrodje MSF se zavzema za dobro obvladovanje projekta (angl. project governance), ki

zagotavlja ravno prav procesov, napotkov, rigoroznosti in preglednosti nad izvajanjem

projekta ter je namenjeno učinkoviti in uspešni uporabi projektnih virov, izdelavi rešitve in

uravnoteženju omejitev projekta. V opisu poti so naštete diskretne in stalne aktivnosti ter

vloge, odgovorne za njihovo izvajanje. Pot opisujejo aktivnosti (npr. definiranje projektne

listine, definiranje postopka za prevzem izdelkov in izvajanje zaključnega pregleda

projekta) in na poti se izdelajo izdelki (npr. projektna listina, status izdelkov, odziv

uporabnikov in strank ter poročilo o zaključku projekta). Pot je namenjena usmerjanju

aktivnosti realizacije rešitve z namenom ponovljive in zanesljive izdelave rešitve, saj se na

poti vzpostavijo in stalno izboljšujejo procedure in procesi sočasno z optimizacijo in

stalnim izboljševanjem učinkovitosti in uspešnosti skupine ter kakovosti rešitve.

6.6 Discipline ogrodja MSF

Tri discipline, ki so opisane v tem poglavju, in sicer vodenje projektov, upravljanje

usposobljenosti in upravljanje tveganj, so v okviru ogrodja MSF opredeljene kot področja

praks, kjer se uporabljajo različne metode, izrazi in pristopi [7]. Te discipline so

pomembne za optimalno delovanje obeh modelov ogrodja in so prav tako vključene v

ogrodje MOF.

Upravljanje projektov

Ogrodje MSF uporablja porazdeljen skupinski pristop k vodenju projektov, ki se nanaša na

značilnosti (še posebej vzpostaviti jasno polaganje računov in deljeno odgovornost ter dati

pooblastila članom skupine) in na oba modela. Prakse projektnega vodenja v ogrodju

povečujejo osebno odgovornost članov skupine in omogočajo skalabilnost od majhnih do

zelo velikih, kompleksnih projektov. Obstaja več značilnosti pristopa MSF k vodenju

projektov, ki skupaj tvorijo disciplino vodenja projektov ogrodja MSF.

Nekatere izmed njih so [6]:

● projektno vodenje je disciplina, utelešena v nizu široko sprejetih področij znanj in

aktivnosti, v nasprotju z vlogami ali nazivi delovnih mest,

56

● večina odgovornosti vloge, ki se običajno imenuje vodja projekta, je zajeta v

zagovorniški skupini vodenje programa,

● pri večjih projektih, ki zahtevajo velikostno razširitev skupinskega modela, se aktivnosti

projektnega vodenja pojavljajo na več nivojih,

● zelo veliki ali kompleksni projekti zahtevajo specialista ali skupino za vodenje

projektov,

● odločitve se sprejemajo s konsenzom, kar je v nasprotju s klasičnimi metodami

projektnega vodenja, kjer vodja projekta sprejema ključne odločitve ter izvaja nadzor

in ima določena pooblastila nad ostalimi člani skupine.

Upravljanje tveganj

Pomemben vidik upravljanja projektov je nadzor nad tveganji projekta, ki jih lahko v

splošnem definiramo kot možnosti izgube. Tveganja se navezujejo na predvidevanje

težav ali napak, na negotovost, ki spremlja projektne odločitve in njihove posledice, na

možnosti neugodnih izidov ali na morebitno izgubo vrednosti, nadzora, funkcionalnosti in

kakovosti [7]. Upravljanje tveganj je v ogrodju MSF proaktivno, kar pomeni, da ima

projektna skupina definiran in viden proces za upravljanje tveganj. Tako je potrebno

tveganja najprej identificirati, jih jasno opredeliti, nato pa jih analizirati in razvrstiti glede na

verjetnost nastopa in učinek v primeru pojava. Na podlagi razvrstitve tveganj je potrebno

definirati akcije, ki bodo ublažile učinke posameznih tveganih pojavov in te integrirati v

projektni plan. Sledi spremljanje in nadzor tveganj med izvedbo projekta. Ostane še zajem

in hramba novih in spremenjenih tveganj, klasifikacij, rezervnih planov tveganj, planov za

zmanjševanje tveganj in priporočil za spremembe v politiki in smernicah v bazi znanja

tveganj. Le-ta je pomemben element učeče se organizacije, saj predstavlja osnovo za

nenehne izboljšave na področju upravljanja tveganj.

Upravljanje usposobljenosti

Disciplina se ukvarja z identifikacijo znanj, potrebnih za izvedbo projekta, razpoznavo

potenciala znotraj podjetja in skupine ter pridobivanjem manjkajočih znanj in veščin z

minimalnim vplivom identificiranega primanjkljaja na izvedbo projekta. Primanjkljaj

ustreznih kadrov se po filozofiji MSF obravnava kot priložnost za širitev obzorij zaposlenih

in pridobivanje novih znanj kot izkušnja, nikakor pa ne kot potencialen problem pri izvedbi

projekta. [9] Disciplina med drugim opisuje tudi proces upravljanja usposobljenosti oz.

57

optimiranje znanj skupine. Začetni korak v tem procesu je definicija potrebnih

sposobnosti, v drugem se ugotavljajo manjkajoča znanja in izdelajo plani učenja, ki se

nato v tretjem koraku izvedejo in v zadnjem ovrednotijo.

58

7 PRIMERJAVA OGRODIJ RUP IN MSF

To poglavje definira kriterije (točke) primerjave obeh ogrodij. Tako smo primerjali

značilnosti, discipline, faze in poti, vloge, izdelke, pristope k prilagoditvi in inačice,

dopolnilna ogrodja ali procese ter podporna orodja. Pri tem smo uporabljali literaturo s

podobno vsebino, npr. [2, 7, 29, 30].

Pri primerjavi značilnosti obeh ogrodij smo upoštevali tudi osem načel, ki so opredeljena

kot smisel (angl. spirit) ogrodja RUP [11] (povezujejo ogrodje RUP z izkušnjami pri njegovi

uporabi), šest ključnih načel za poslovno usmerjen razvoj (angl. business driven

development) [14] ter deset bistvenih načel ogrodja RUP, ki opisujejo učinkovit proces

razvoja [14].

7.1 Značilnosti

Postavitev skupne vizije – značilnost ogrodja MSF

Pri obeh ogrodjih je postavitev skupne vizije tista osnova, ki zelo pripomore k uspehu

projekta. Obe ogrodji poudarjata skupno izdelavo in soglasno sprejetje vizije s strani

ključnih deležnikov (ogrodje RUP) in vseh zagovorniških skupin (ogrodje MSF). Za obe

ogrodji je zelo pomembno, da so vsi člani skupine in drugi deležniki seznanjeni ter da

razumejo vsebino skupne vizije, saj ta podaja skupne usmeritve, poenostavlja in

zagotavlja konsistentnost v sprejemanju odločitev, motivira skupino ter ohranja fokus na

kakovosti.

Upravljanje zahtev – značilnost ogrodja RUP

Ogrodje RUP značilnost upravljanje zahtev opiše v disciplini zajemanje zahtev (poglavje

5.5), ki vključuje tudi zmožnostni vzorec zahteve. Ta upravljanje zahtev predstavi z atributi

opis vzorca, strukturirana členitev dela (diagram delovnega toka in členitev dela),

dodelitev skupine in uporaba izdelkov. Ogrodje MSF lastnost upravljanje zahtev opiše

59

manj podrobno, s posameznimi aktivnostmi (npr. definiranje visokonivojskih zahtev) na

poteh vzpostavitev projekta in planiranje. Potrebe, lastnosti sistema in zahteve deležnikov

(ogrodje RUP) lahko konceptualno enačimo z visokonivojskimi zahtevami ogrodja MSF

(pri obeh so namenjeni izdelavi bolj podrobnih zahtev). Ogrodje MSF predlaga za to vrsto

zahtev dokumentiranje v specifikacijah, predstavitev v orodjih za modeliranje in

načrtovanje ter opis v obliki uporabniških zgodb. Model primerov uporabe in dodatne

specifikacije (ogrodje RUP) pa lahko konceptualno enačimo z nizkonivojskimi zahtevami

ogrodja MSF (pri obeh osnova za načrtovanje), ki so v slednjem dokumentirane v

funkcionalni specifikaciji. Za zbiranje zahtev obe ogrodji predlagata iste tehnike, in sicer

intervjuja, vprašalnikov in pregledovanja obstoječe dokumentacije. Ogrodje RUP še

dodatno opiše tehniko zgodborisov, ogrodje MSF pa dodatno predlaga tehnike

opazovanja, prototipiranja in merjenja.

Nadzor nad spremembami – značilnost ogrodja RUP

Ogrodje RUP podrobno opisuje (v disciplini upravljanje konfiguracij in sprememb oz. v

zmožnostnem vzorcu upravljanje konfiguracij in sprememb), kako nadzorovati, slediti in

spremljati spremembe v uspešnem iterativnem razvoju. Prav tako opisuje varne delovne

prostore (angl. work spaces) za razvijalce, da se zagotovi neodvisnost od sprememb,

narejenih v drugih delovnih prostorih, in nadzor nad spremembami vseh izdelkov

programske opreme (modelov, kode, dokumentov itd.). Ogrodje MSF ne predpisuje

posebnega sklopa postopkov za upravljanje sprememb, ker so ti, odvisno od velikosti in

narave projekta, lahko preprosti ali obsežni. Na kratko opiše le sedem elementov

učinkovitega nadzora nad spremembami (npr. učinkovit nadzor nad spremembami

zahteva učinkovito upravljanje konfiguracije). Vendar pa lahko IT-podjetja/organizacije bolj

podrobne napotke glede upravljanja konfiguracije in sprememb najdejo v

komplementarnem ogrodju MOF.

Uporaba komponentnih arhitektur – značilnost ogrodja RUP

Razvoj na osnovi ogrodja RUP se osredotoča na izdelavo izvršljive, robustne in stabilne

arhitekture sistema, ki je prav tako fleksibilna, intuitivno razumljiva, naklonjena

spremembam in spodbuja učinkovito ponovno uporabo. Arhitektura sistema se v ogrodju

RUP z uporabo modela 4 + 1 pogledov na arhitekturo (angl. 4 + 1 view model of

architecture) tudi ustrezno opiše ter dokumentira. Arhitektura v ogrodju RUP ne izraža le

60

strukture in obnašanja, ampak tudi uporabnost, funkcionalnost, učinkovitost, prožnost,

odpornost, ponovno uporabo, estetiko, razumljivost, ekonomske in funkcionalne omejitve

ter sklenjene kompromise. Ogrodje MSF predlaga izgradnjo konceptualne arhitekture na

poti vzpostavitve projekta in izgradnjo arhitekture rešitve ter arhitekture implementacije na

poti planiranja projekta. Vse naštete arhitekture so opisne in ne izvršljive narave.

Pomembna razlika v navezavi z arhitekturo sistema med obema ogrodjema je torej ta, da

ogrodje MSF ne temelji na izdelavi izvršljivega ogrodja rešitve (arhitekture). Pri obeh

ogrodjih pa se srečujemo s komponentno osnovanimi arhitekturami rešitev.

Ostati agilen, pričakovati spremembe in prilagajanje – značilnosti ogrodja MSF

Kljub temu da ima ogrodje MSF le malo ali nič vpliva na pojav sprememb, zagotavlja

urejen, preverjen in agilen način ravnanja s spremembami, ko se te pojavijo, in sicer z

uporabo odprte komunikacije in opolnomočenja. MSF na ta način omogoča skupinam, da

se vedejo agilno in se odzivajo na spremembe [7]. Ta značilnost ogrodja MSF v splošnem

velja za vsako iterativno inkrementalno metodo razvoja IT-rešitev. Spremembe in

prilagajanje so namreč stalnica takšnega pristopa. Načelo smisla ogrodja RUP, ugoditi

zahtevam po spremembah na začetku projekta, naslavlja koncept sprememb te

značilnosti v ogrodju RUP.

Dati pooblastila članom skupine – značilnost ogrodja MSF

Osnova za pooblaščanje oz. opolnomočenje članov skupine je vzpostavitev nehierarhične

strukture oz. enakopravnosti pri odločanju med vsemi zagovorniškimi skupinami ogrodja

MSF. Priprava članov skupine za opolnomočeno opravljanje posameznih opravil oz. tipov

opravil je postopek, ki vodi od nepripravljenosti do visoke pripravljenosti za

opolnomočenje. Ta postopek opisuje model situacijskega vodenja (angl. situational

leadership model), ki je opisan v ogrodju MSF. Opolnomočene projektne skupine ogrodja

MSF prevzemajo odgovornosti za upravljanje s tveganji projekta in usposobljenostjo

skupine in s tem proaktivno upravljajo tako s tveganjem kot usposobljenostjo [7]. Izdelava

in upravljanje terminskega plana predstavlja še en primer opolnomočenja. Ogrodje MSF

namreč zagovarja terminiranje od spodaj navzgor (angl. bottom up scheduling), kar

pomeni, da člani skupine sami postavljajo časovnice glede dela, ki ga bodo opravili, in

sprejemajo zaveze, da bo to tudi narejeno oz. pravočasno obveščajo, če temu ne bo tako.

Opolnomočeni člani skupine pogosto čutijo večjo odgovornost oz. raje polagajo račune za

61

svoje odločitve in prav tako lažje sprejemajo soodgovornost. Ogrodje RUP ne definira

koncepta opolnomočenja. Vodenje projektov v ogrodju RUP tudi ni deljeno med

posamezne vloge oz. posamezne člane skupine. Ogrodje RUP v ta namen definira in

opisuje vlogo vodja projekta.

Vizualno modeliranje – značilnost ogrodja RUP

Ogrodje RUP uporablja za izdelavo številnih vizualnih specifikacij IT-rešitev standardni

modelirni jezik UML. Ogrodje MSF to značilnost pušča odprto.

Vzpostaviti jasno polaganje računov in deljeno odgovornost – značilnost ogrodja MSF

Značilnost je vgrajena v vsak vidik obvladovalnega modela ogrodja MSF, ki zato jasno

odraža polaganje računov ene zagovorniške skupine oz. vloge in je podprt z deljeno

odgovornostjo (npr. posamezna vloga polaga račun ob zaključku vmesne ali glavne

kontrolne točke, vendar je uspeh odvisen od usklajenega delovanja in skupne

odgovornosti z drugimi vlogami) [7]. Značilnost vzpostaviti jasno polaganje računov in

deljeno odgovornost se odraža tudi v skupinskem modelu MSF, kjer je z namenom

jasnega polaganja računov o svojem delu, vsaka zagovorniška skupina povezana s točno

določenim ciljem kakovosti, obenem pa je skupno odgovorna za uspeh projekta [7].

Ogrodje RUP na najnižjem nivoju abstrakcije odgovornosti definira izdelke, za katere je

določena vloga odgovorna. Na nivoju aktivnosti določa skupino vlog, ki sodeluje pri

njenem izvajanju. Na najvišjem nivoju abstrakcije odgovornosti, odgovornost za izvedbo

posameznih iteracij in faz dodeli vodji projekta. Za razliko od ogrodja MSF vloge v ogrodju

RUP ne polagajo računov določenim deležnikom in si prav tako ne delijo odgovornosti za

izdelavo posameznih izdelkov ali vidikov rešitve. Značilnost pa lahko kljub temu zasledimo

v disciplini okolje ogrodja RUP, ki priporoča, da si posamezne vloge porazdelijo

odgovornost za posamezne dele procesa in povezana orodja, vendar pa morajo biti

skupno odgovorne za izboljšanje celotnega procesa. V tem primeru lahko vloga procesni

inženir odigra osrednjo orkestralno vlogo. V obeh ogrodjih je vsak posamezni član skupine

odgovoren za tisti del ali dele rešitve, ki so mu dodeljeni, vendar pa je za rešitev kot celoto

(sistem) v ogrodju RUP odgovorna oseba ali osebe v vlogi vodje projekta v nasprotju z

ogrodjem MSF, kjer je ta vrsta odgovornosti porazdeljena med člane skupine.

62

Značilnosti, povezane s komunikacijo (gojiti odprto komunikacijo, učiti se iz vseh izkušenj,

partnerstvo s strankami) – značilnosti ogrodja MSF

Obe ogrodji gojita odprto komunikacijo, saj imajo posamezniki in skupine za uspešno ter

optimalno opravljanje svojega dela zmeraj na voljo aktivno deljene in primerne

informacije. Prav tako nobeno od ogrodij ne temelji na scenariju, po katerem posamezni

člani skupine ne bi želeli deliti vmesnih rezultatov svojega dela in bi v skrajnem primeru

celo uporabljali svoje znanje in informacije kot moč ter jih delili po načelu: čim manj, tem

bolje.

Ogrodje MSF predpostavlja, da osredotočenje na nenehno učenje vodi do večjega

uspeha. Znanje, pridobljeno na enem projektu, mora biti zato dostopno tudi v naslednjih

projektih, ker se s tem poveča verjetnost sprejemanja dobrih odločitev. Ogrodje MSF

podpira značilnost učiti se iz vseh izkušenj s pomočjo pregledov v kontrolnih točkah, in

sicer naravnih kontrolnih točkah (angl. natural checkpoints), planiranih kontrolnih točkah

(angl. planned checkpoints) in kontrolnih točkah, dodanih s strani organizacije (angl.

externally facilitated checkpoints) [7]. V ogrodju RUP je značilnost z upravljalskega vidika

prisotna ob ocenjevanju iteracij, s tehničnega vidika pa je opisana v disciplini okolje (npr.

načini za podajanje znanja o procesu in orodjih, vloga mentorjev itd.).

Ogrodje MSF podpira značilnost partnerstvo s strankami v modelu skupine, ki predstavlja

model zagovorništva in za zagovornika do stranke določa vlogo produktni vodja. Vloga

produktni vodja sodeluje s stranko ali strankami pri izdelavi in prilagajanju vizije,

razumevanju in izpolnjevanju pričakovanj, obveščanju o pojavu novih tveganj itd. V

ogrodju RUP je vloga projektni vodja odgovorna za stik med strankami in projektno

skupino. Stranka je večinoma vključena v definiranje, nadziranje in validiranje zahtev

sistema v prvi in drugi fazi ogrodja. Stranka prav tako ob zaključku vsake od iteracij

posreduje projektni skupini povratne informacije glede izdaje rešitve.

Zagotavljanje kakovosti – skupna lastnost

Ogrodje RUP preverja kakovost rešitve, procesa in izdelkov ob koncu vsake iteracije s

pomočjo dobro definiranega postopka pregleda. Ogrodje določa, da je za zagotavljanje

kakovosti rešitve in procesa odgovorna celotna projektna skupina. Odgovornost za

kakovost posameznih izdelkov in delov procesa pa prevzemajo tisti člani skupine, ki

63

neposredno sodelujejo v posameznih segmentih procesa oz. izdelujejo določene izdelke.

Zato je vidik kakovosti vključen v skoraj vsa opravila ogrodja. Ogrodje prav tako vsebuje

številne napotke, povezane s kakovostojo (koncepte, šablono, podporni material in

smernici). Odgovornost za upravljanje, merjenje in doseganje skupne kakovosti rešitve

ogrodje posreduje vlogi vodja projekta. Zagotavljanje kakovost je v ogrodju MSF vključeno

v vsak vidik ogrodja [7]. Vsak član skupine je odgovoren za doseganje stopnje kakovosti,

povezane z njegovim delom in izdelki ter za doseganja ciljev kakovosti (tabela 7), ki se

nanašajo na vlogo (vloge), ki jo izvaja. S tem pa je tudi odgovoren za doseganje skupne

kakovosti rešitve, saj je le ta v ogrodju MSF deljena med vseh sedem, enako pomembnih

vlog. V ogrodju MSF najdemo v navezavi s to značilnostjo tudi koncept kakovost storitev

in dve funkcionalni območji (zagotavljanje procesov in upravljanje kakovosti produkta), ki

ju izvaja vloga programski vodja.

7.2 Discipline

Ogrodje RUP opisuje devet disciplin, ogrodje MSF pa tri discipline. Discipline obeh ogrodij

ter zagovorniške skupine oz. vloge ogrodja MSF se pojavljajo z različno intenzivnostjo v

celotnem življenjskem ciklu projekta (slika 4 in slika 10). Opozorimo, da obe sliki

prikazujeta oceno intenzivnosti pojava zagovorniških skupin v agilni inačici ogrodja MSF

oz. disciplin v konfiguraciji ogrodja RUP za velike projekte. Vsebinsko povezavo ponazarja

tabela 7.

Tabela 7: Primerjava disciplin ogrodja RUP z disciplinami in vlogami ogrodja MSF

Discipline ogrodja RUP

Zagovorniške skupine in discipline ogrodja MSF

poslovno modeliranje vodenje produkta

zajemanje zahtev vodenje produkta zadovoljstvo uporabnikov

analiza in načrtovanje arhitektura

implementacija razvoj

testiranje testiranje

okolje izdaja/obratovanje vodenje programa disciplina upravljanja usposobljenosti

vodenje projektov vodenje programa disciplina upravljanje tveganj disciplina projektno vodenje

upravljanje konfiguracije in sprememb

ogrodje MOF

dobava izdaja/obratovanje

64

7.3 Faze in poti

Ogrodje MSF razdeli poti na sedem glavnih kontrolnih točk (vizija/obseg odobrena,

projektni plan odobren, obseg zaključen, pripravljenost na predajo zaključena, namestitev

zaključena in sprejem s stani stranke) in predlaga več notranjih kontrolnih točk. Glavne

kontrolne točke označujejo dokončanje glavnih izdelkov in zaključek glavnih aktivnosti po

načelu polaganja računa posamezne vloge, vendar s sodelovanjem vseh zagovorniških

skupin. Projektne skupine vmesne kontrolne točke uporabljajo za označevanja napredka

znotraj poti in segmentiranja dela v lažje obvladljive enote ter izvajanje pregledov (ti se

izvajajo tudi v glavnih kontrolnih točkah) [7]. Ogrodje MSF predlaga segmentiranje dela na

poteh v delovne tokove (angl. work streams) in steze (angl. swim lines). V ogrodju RUP se

prva generacija rešitve izdela v začetnem razvojnem ciklu, ki ga sestavljajo štiri faze

(začetna, zbiranje informacij, konstrukcija in prevzem), z glavnimi mejniki ob koncu vsake

od njih. Znotraj posameznih faz poteka razvoj v časovno omejenih (angl. timeboxed) in

planiranih iteracijah oz. izvršljivih korakih. Če se življenjska doba rešitve na tej točki ne

konča, se razvoj nadaljuje v evolucijskih ciklih, ki rezultirajo v novih generacijah rešitve.

Ogrodje MSF predlaga za razvoj, ki je okvirno daljši od šestih mesecev in z več kot

petinsedemdeset člansko skupino, strategijo izdaj označenih z verzijo (angl. versioned

released strategy), kjer se rešitev gradi v več iteracijah oz. prehodih po vseh petih poteh.

V vsaki iteraciji se izdela izvršljiv inkrement rešitve (izdaja rešitve), ki je korak bližje

končni, dokončani rešitvi oz. generaciji rešitve po ogrodju RUP (slika 14).

Slika 14: Izdaje označene z verzijo

65

Posamezne faze ogrodja RUP, kjer se z zaporednim prehodom skozi vse štiri faze zgradi

nova generacija IT-rešitve, ni mogoče neposredno primerjati s posameznimi potmi ogrodja

MSF, kjer prehod po vseh petih poteh z uporabo strategije izdaj, označenih z verzijo,

izdela izvedljivo verzijo rešitve. Smiselno je konceptualno povezati posamezne izvršljive

korake obeh ogrodij (iteracije ogrodja RUP in označene verzije ogrodja MSF) oz.

discipline ogrodja RUP in poti ogrodja MSF.

7.4 Vloge

Vloge v ogrodju RUP so osnovane na odgovornostih, ki so povezane z izdelavo določenih

izdelkov in smo jih razdelili v skupini glavnih in obrobnih vlog (tabela 4). Ogrodje MSF

opisuje sedem vlog, ki so osnovane na množicah aktivnosti. Število vlog v obeh ogrodjih

podaja tabela 8.

Tabela 8: Število vlog ogrodij RUP in MSF

Vloge

Ogrodje RUP Ogrodje MSF

glavne vloge 27 7

obrobne vloge

5

skupaj 32 7

V tabeli 9 smo usmeritve vloge produktni vodja ogrodja MSF na posameznih poteh [7]

konceptualno povezali z vlogami v ogrodju RUP.

66

Tabela 9: Konceptualna preslikava vloge produktni vodja v vloge ogrodja RUP

Usmeritve po posameznih poteh

Konceptualna preslikava v vloge ogrodja RUP

vzpostavitev projekta

poslovna vizija poslovni arhitekt

identifikacija potreb strank analitik poslovnega procesa, poslovni arhitekt, poslovni načrtovalec

zahteve popisovalec zahtev

definicija vizije/obsega sistemski analitik

kriteriji sprejemljivosti za stranke vodja projekta

planiranje

konceptualni načrt -

analiza poslovnih zahtev vodja projekta

plan komuniciranja -

prioritete med zahtevami -

izgradnja

pojasnjevanje obsega, zahtev in pričakovanj deležnikov

vodja projekta

tržne poti in prodajni pripomočki -

stabilizacija

izvajanje plana komuniciranja -

prioritete med soglasji glede obsega -

dobava

ocenitev povratnih informacij strank vodja projekta

odobritev vsake enote dobave -

obvladovanje

potrditev s strani strank vodja projekta

Iz tabele 9 je razvidno, da lahko vlogo produktni vodja ogrodja MSF (ogrodje RUP ne

pozna te vloge) konceptualno preslikamo v naslednje vloge ogrodja RUP: analitik

poslovnega procesa, poslovni arhitekt, poslovni načrtovalec, popisovalec zahtev,

sistemski analitik ter vodja projekta. V tabeli 9 smo usmeritve, ki jih v ogrodju RUP ne

zasledimo, ustrezno označili, npr. usmeritev prioritete med zahtevami je namenjena

implementaciji strategije izdaje označene z verzijo, ki je ogrodje RUP ne pozna. Prav tako

lahko usmeritev definicija vizije/obsega konceptualno pridružimo vlogi RUP le v delu, ki

naslavlja izdelavo skupne vizije.

7.5 Izdelki

Izdelki ogrodja RUP so zmeraj rezultat izvedbe podrobnega opisa opravil. Izdelki ogrodja

MSF so našteti v okviru posameznih poti, ki podajajo nekaj ali pa nič opisa izdelkov.

Večina izdelkov ogrodja MSF se lahko preslika v izdelke ogrodja RUP (npr. izdelek testirni

načrt v ogrodju MSF v izdelek testirni načrt v ogrodju RUP), kar pa obratno ne velja, saj

67

ima ogrodje RUP več izdelkov, ki jih ne zasledimo v ogrodju MSF (npr. izdelka razvojni

primer v ogrodju RUP ne zasledimo v ogrodju MSF).

7.6 Pristopi k prilagoditvi in inačice

Disciplina ogrodja RUP, imenovana okolje, podrobno opisuje postopek prilagajanja

ogrodja na nivoju organizacije in projekta, z ali brez uporabe orodja RMC, ki omogoča

dodatno nastavljanje (angl. customize) ogrodja s strani uporabnika oz. procesnega

inženirja. V ogrodju lahko najdemo tudi primer prilagoditve ogrodja majhni organizaciji.

Postopek načrtovanja in izgradnje inačice (npr. RUP for System Z) s pomočjo orodja RMC

v ogrodju RUP ni zajet in je opisan v [26]. Posamezna inačica je shranjena v knjižnici IBM

RUP orodja RMC v obliki vtičnika metode, ki mu je lahko pridružena ena ali več

konfiguracij. Nekaj inačic ogrodja RUP je naštetih v tabeli 10.

Ogrodje MSF podrobno opisuje velikostno prilagoditev skupinskega modela. Tako v

primeru povečanja obsega ali števila članov projekta uvaja skupine po funkciji (angl.

function team) in/ali skupine po funkcionalnosti (angl. feature teams). V primeru da na

projektu sodeluje manj kot sedem članov, ogrodje MSF podaja priporočila, katere vloge je

mogoče, nemogoče ali ni priporočljivo združiti. Najmanjše število članov skupine je s tem

omejeno navzdol na tri. Napotke za prilagoditev ogrodja MSF je možno zaslediti tudi v

disciplini projektno vodenje, kjer je opisano, kako porazdeliti aktivnost vodenja v primeru

večjih in kompleksnejših projektov. Podpornemu orodju Visual Studio Ultimate 2013 so

pridružene tri inačice, naštete v tabeli 10.

Tabela 10: Inačice ogrodij RUP in MSF

Inačice ogrodja RUP

Inačice ogrodja MSF

RUP for SOA, Classic RUP for Large Projects, RUP for Small Projects, COTS Package Delivery, System Engineering, Asset Based Development, RUP for System Z, Enterprise Unified Process

MSF for Agile Software Development MSF for CMMI Process Improvement Microsoft Visual Studio Scrum

68

7.7 Dopolnilna ogrodja ali procesi

Ogrodje MSF je tesno povezano z ogrodjem MOF (slika 8) in skupaj predstavljata

življenjski cikel tehnoloških rešitev podjetja Microsoft oz. ogrodje ESP (Enterprise Service

Framework). Ogrodje MOF podaja tehnične napotke, ki omogočajo organizacijam

doseganje zanesljivosti, razpoložljivosti in upravljivosti poslovno kritičnih sistemov, ki so

zgrajeni na podlagi Microsoftovih produktov in tehnologij. Napotki MOF naslavljajo ljudi,

procese, tehnologijo in upravljanje ter so potrebni za izvajanje kompleksnih, porazdeljenih

in heterogenih IT-okolij. IT-podjetja/organizacije uporabljajo MSF za razvoj in uvedbo

rešitev ter MOF za njihovo neprekinjeno izvajanje in upravljanje. MSF in MOF si delita

značilnosti in discipline. Razlikujeta se v uporabi, saj vsak uporablja specifična modela

(skupinski in obvladovalni) ter specifične uveljavljene prakse (angl. proven practices).

MSF ponazori strukturo skupine in aktivnosti z vidika razvoja rešitev, medtem ko MOF z

vidika upravljanja. V MSF je poudarek na projektih, v MOF pa na izvajanju produkcijskega

okolja [7].

Ogrodje RUP je shranjeno v knjižnici IBM RUP orodja RMC v obliki vtičnikov RUP Base in

RUP Business Modeling. Vtičnik RUP Base vsebuje poleg vsebine tudi tri procese: classic

RUP, small RUP in medium RUP. Proces classic RUP vsebuje tudi vse elemente vtičnika

RUP SOMA in je v privzeti obliki HTML (angl. Hyper Text Merkup Language) ogrodja RUP

(konfiguracija Classic RUP for SOMA) tudi objavljen. V diplomski nalogi smo privzeli, da

so elementi storitveno usmerjenega razvoja prilagoditev ogrodja RUP (zato izdelke in

vlogo vtičnika RUP SOMA nismo upoštevali). S tem je RUP SOMA dopolnilni proces

ogrodja RUP.

7.8 Podpora orodij

Ogrodje RUP podaja napotke, mentorje za IBM Rational orodja, ogrodje MSF pa pušča to

področje odprto. V tabeli 11 smo klasificirali orodja, ki so opisana v mentorjih orodij

ogrodja RUP in dodali orodje Rational Team Concert (zgrajeno na novi IBM-ovi platformi

Jazz), ki ima svojega mentorja v standardni konfiguraciji RUP v knjižnici IBM Practices

orodja RMC. Pri podpori vseh področij, ki jih podaja tabela 11 v navezi z ogrodjem MSF,

pa se lahko uporabita najnovejši tehnologiji podjetja Microsoft, Visual Studio 2013

69

Ultimate in Team Foundation Server 2013. Naj poudarimo, da je na tržišču veliko

odprtokodnih aplikacij, ki jih lahko uporabimo z obema ogrodjema.

Tabela 11: Podporna orodja ogrodij RUP in MSF

Področja

Ogrodje RUP Ogrodje MSF

upravljanje zahtev Rational RequisitePro Visual Studio 2013 Ultimate z Team Foundation Server 2013

analiza in načrtovanje Rational Rose, Rational Suit AnalystStudio

implementacija Rational Application Developer

testiranje Rational PurifyPlus, Rational Robot, Rational TestFactory, Rational TestManager

vodenje projekta Rational ProjectConsole

upravljanje konfiguracij in sprememb

Rational ClearCase, Rational ClearQuest

prilagajanje, konfiguriranje in objavljanje procesov

Rational Method Composer

uprizarjanje procesov Rational Team Concert

70

8 ZAKLJUČEK

Ogrodje RUP je dostopno v elektronski obliki v nekaj tisoč spletnih straneh z iskalnikom

po vsebini in terminološkim slovarjem, kar povečuje njegovo uporabnost z ozirom na

zadnjo verzijo ogrodja MSF, ki je na voljo le v fizični obliki. Razlika med ogrodjema, ki je

zelo očitna, je, da ogrodje MSF ne pozna vloge vodja projekta in zato uvaja v veščino

projektnega vodenja koncepte opolnomočenja, polaganja računov in deljene

odgovornosti. Ogrodje MSF tudi ne opisuje discipline upravljanja konfiguracij in sprememb

ter je dopolnilno ogrodju MOF, ki podaja ustrezne napotke v zvezi s to disciplino. Razlika

je tudi v izvajanju večjih projektov. Tukaj se izkaže, da neposredna konceptualna

povezava med posameznimi potmi in fazami obeh ogrodij ni smiselna. Procesi razvoja so

bili zmeraj podprti s primernimi orodji. Kljub temu, da je na tržišču veliko odprtokodnih

aplikacij, ki jih lahko uporabimo z obema ogrodjema, ogrodje RUP podaja napotke,

mentorje za IBM Rational orodja, ogrodje MSF pa pušča to področje odprto. Razlike so

tudi v številu vlog, izdelkov, disciplin in inačic, kjer prednjači ogrodje RUP. Od vseh vrst

napotkov, ki so opisani v ogrodju RUP, ogrodje MSF vsebuje le nekaj primerov. Vsaj

nekaj smernic, praks in šablon izdelkov, četudi z bolj ohlapnimi navodili za njihovo

izdelavo, bi znatno olajšalo učenje in uporabo ogrodja MSF. Poleg opisanih razlik pa se

ogrodji zelo dobro dopolnjujeta na nekaterih področjih. Ogrodje RUP natančno in obsežno

opiše poslovno modeliranje, področje, ki je danes v industriji IT še kako pomembno,

ogrodje MSF pa opiše zelo dobro disciplini upravljanja tveganj in usposobljenosti. Ogrodji

imata veliko skupnih značilnosti. Te so iterativno inkrementalni razvoj, postavitev skupne

vizije, upravljanje zahtev, uporaba komponentnih arhitektur, pričakovanje sprememb,

polaganje računov oz. odgovornosti vlog in posameznikov, zagotavljanje kakovosti, odprta

komunikacija med člani skupine, nenehno učenje, pričakovanje sprememb in uporabniška

usmeritev. Zelo pomembni vodili obeh ogrodij sta tudi zgodnje razreševanje tveganj in

pogoste inkrementalne izdaje. Pokazali smo, da lahko vlogo produktni vodja ogrodja MSF,

ki jo ogrodje RUP ne opisuje, konceptualno povežemo s določenimi vlogami ogrodja RUP.

Podobno lahko storimo tudi za preostale vloge ogrodja MSF. V diplomski nalogi smo

opisali ocenjevanje procesov po modelu CMMI in za podjetja, ki uspešno implementirajo

ogrodje RUP v svoje delovno okolje je značilno, da lahko dosegajo nivoje tri ali štiri. Na

drugi strani pa ogrodje MSF podaja inačico CMMI, ki je za razliko od agilne inačice

71

namenjena večjim projektom in podpira tretji nivo stopenjske predstavitve modela CMMI.

Ker ogrodje RUP vsebuje veliko vsebine in ogrodje MSF veliko manj, je prilagajanje obeh

ogrodij po prvem in drugem scenariju, ki smo ju opisali v diplomski nalogi, mogoče le v

podjetjih, ki imajo v svojih razvojnih skupinah tudi strokovnjake s procesnimi izkušnjami.

Tretji scenarij vključuje prilagajanje inačic ogrodij, kar v primeru ogrodja MSF pomeni bolj

konkretno vsebino in s tem večjo možnost učinkovitega in uspešnega samostojnega

prilagajanja. V ogrodju RUP je samostojno prilagajanje mogoče v primeru inačice za

majhne projekte, saj le ta zmanjšuje njegovo kompleksnost. V vseh treh scenarijih smo

predpostavili prilagajanje celotne vsebine ogrodij, kar pa je v praksi zelo malo verjetno.

Običajno je, da podjetja izberejo le tiste dele ogrodij, ki jim zagotavljajo izboljšanje

njihovega trenutnega procesa razvoja. V primeru ogrodjij RUP in MSF to zagotavlja večjo

možnost za samostojno prilagajanje. Proces razvoja smo definirali kot opis spremenljivk

kdo, kaj, kako in kdaj. Ogrodje RUP striktno sledi podani definiciji z natančnimi in

obsežnimi opisi vlog, izdelkov, opravil ter procesov, ki imajo osnovo v standardnem

metamodelu. Ogrodje MSF ne opisuje spremenljivke kako oz. opravil, ostale tri

spremenljivke pa opisuje veliko manj obsežno in natančno. Na podlagi slednjega lahko

trdimo, da je ogrodje RUP tehnično bolj dovršeno ogrodje. Po drugi strani pa najdemo v

ogrodju MSF napotke o tem, kako vzpostaviti in voditi uspešne in učinkovite skupine, ki

delujejo na nehierarhični osnovi, s čimer ogrodje MSF, za razliko od ogrodja RUP,

posega na področje socialne psihologije.

.

.

72

VIRI

[1] Peter Haumer. IBM Rational Method Composer: Key concepts: Part 1. IBM

developerswork, 15.12.2005. Dostopno na

http://www.ibm.com/developerworks/rational/library/dec05/haumer/, marec 2012

[2] Aleš Živkovič. Razvoj programske opreme z uporabo jezika UML. Uporabna

Informatika številka 4 – letnik VIII. Slovensko društvo INFORMATIKA, 2000

[3] Ivar Jacobson, Grady Booch, James Rumbaugh. The Unified software

development process. Addison Wesley Longman, Inc., 1998.

[4] Ahmad K. Shuja, Jochen Krebs. IBM Rational Unified Process Reference and

Certification Guide. IBM Press, 2008.

[5] Marlys Powers, Jeff Carter, Geof Lory, Andrew McMurray. MSF a pocket guide. Van

Haren publishing, 2006.

[6] Microsoft Frameworks, 2002. Microsoft Solution Framework 3.0 Overview. Dostopno

na http://download.microsoft.com/.../MSF_v3_Overview%20Whitepaper.pdf,

januar 2012.

[7] Michael S.V. Turner. Microsoft Solution Framework Essentials. Microsoft Press, 2006.

[8]. József Györkös. Organizacija in vodenje informacijskih obdelav. FERI Maribor,

Inštitut za informatiko, 1996.

[9] Aleš Živkovič. Kako združiti nezdružljivo ali MSF U RUP. COTL, pomlad 2004.

Dostopno na http://cot.uni-mb.si/cotl/pomlad2004/zivkovic.html, marec 2013.

[10] Grady Booch, Robert C Martin, James Newkirg. The Process. Dostopno

na http://www.objectmentor.com/resources/articles/RUPvsXP.pdf, marec 2012.

[11] Per Kroll, Philipe Kruchten. The Rational Unified Process made easy. Pearson

Education, Inc., 2003.

[12] Carnegie Mellone Software Engineering Institute, 2006. CMMI for Development,

Version 1.2. Dostopno na http://www.sei.cmu.edu/reports/06tr008.pdf, maj 2013.

[13] Aleks Weitzer. Primerjava in vrednotenje procesov razvoja programske opreme.

Mag. delo, Univerza v Ljubljani, Fakultera za računalništvo in informatiko, 2010.

Dostopno na http://eprints.fri.uni-lj.si/1017/.

[14] RUP 7.01. Dostopno na http://www-03.ibm.com/software/products/us/en/rmc/,

marec 2012.

73

[15] Richard Hundhausend. Working with Microsoft Visual Studio 2005 team

system. Microsoft Press, cop., 2005.

[16] Philippe Kruchten. The Rational Unified Process An Introduction Third Edition.

Pearson Education, Inc., 2004.

[17] The Standish Group, 2009. Chaos summary 2009. Dostopno na

http://www.portal.state.pa.us/portal/.../standish_group_chaos_summary_2009_pdf,

september 2012.

[18] Emris – Enotna metodologija razvoja informacijskih sistemov. Dostopno

na http://www2.gov.si/mju/emris.nsf/Emris?OpenFrameSet, december 2012.

[19] RUP best practicies for software development teams. Dostopno na

http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_b

estpractices_TP026B.pdf, september 2012.

[20] Ian Sommerville. Software engineering, Ninth Edition. Pearson Education,Inc., 2011

[21] Slovensko društvo informatika, 2001-2013. iSlovar. Dostopno na

http://www.islovar.org/iskanje_enostavno.asp, december 2012.

[22] Geir K. Hansen, Hans Westerheim, Finn Olav Bjornson. Tailoring RUP to a

Defined Project Type: A Case Study. Dostopno na

http://www.idi.ntnu.no/grupper/su/publ/bjornson/profes05-hanssen-rup.pdf, maj 2012.

[23] Per Kroll, Bruce Macisaac. Agility and discipline made easy. Addison Wesley

Professional, 2005.

[24] Marjan Pivka. Kakovost v programskem inženirstvu. Desk d.o.o., 1996.

[25] Romana Vajde Horvat. Integracija Zrelostnega modela SEI in standardov ISO

9001,ISO9003. Mag. delo, Univerza v Mariboru Fakulteta za elektrotehniko,

računalništvo in informatiko, 1995.

[26]. RUP for System Z. 2007. Dostopno na

http://www.redbooks.ibm.com/redbooks/pdfs/sg247362.pdf , december 2012.

[27] Johan W.A. Traa. RUP vs. MSF A comparative study. Dostopna na,

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.6759&rep=rep1&type

=pdf, marec 2012.

[28] Maturity Profile Reports. 2013. Dostopno na,

http://cmmiinstitute.com/assets/presentations/2013MarCMMI.pdf, julij 2013.

[29] Katja Kous. Komperativna analiza uveljavljenih postopkov za razvoj programske

opreme. Zbornik osemnajste mednarodne elektrotehne in računalniške konference,

2009.

74

[30] Sandra Sergi Santos. Comparing RUP and MSF. IBM developerworks, 15.4.2007.

Dostopno na,

http://www.ibm.com/developerworks/rational/library/apr07/santos/index.html,

marec 2013.

75

76

77