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
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.