Diplomska naloga: Primarjava procesnih ogrodij RUP in MSF

Transkripcija

1 Fakulteta za elektrotehniko, računalništvo in informatiko Smetanova ulica Maribor, Slovenija Borut Klobasa PRIMERJAVA PROCESNIH OGRODIJ RUP IN MSF Diplomsko delo Maribor, december 2013

2 PRIMERJAVA PROCESNIH OGRODIJ RUP IN MSF Diplomsko delo Študent: Študijski program: Smer: Mentor: Lektorica: Borut Klobasa Univerzitetni študijski program Računalništvo in informatika Informatika red. prof. dr. Marjan Heričko mag. Vesna Gros i

3 ii

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

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

6 ZAHVALA Iskrena hvala red. prof. dr. Marjanu Heričku. Iskrena hvala izr. prof. dr. Jožefu Ritonji. Iskrena hvala Jelki in sestri Bronji. v

7 KAZALO 1 UVOD POMEN PROCESA RAZVOJA INFORMACIJSKIH REŠITEV OCENITEV ZRELOSTI PROCESA RAZVOJA INFORMACIJSKIH REŠITEV PROCESNA OGRODJA ZA RAZVOJ INFORMACIJSKIH REŠITEV OGRODJE RUP Zgodovina Struktura ogrodja RUP Osnovni elementi vsebine Napotki Osnovni elementi procesa Značilnosti ogrodja RUP Najboljše prakse Faze ogrodja RUP Discipline ogrodja RUP OGRODJE MSF Zgodovina Struktura ogrodja MSF Značilnosti ogrodja MSF vi

8 6.4 Vloge ogrodja MSF Poti ogrodja MSF Discipline ogrodja MSF PRIMERJAVA OGRODIJ RUP IN MSF Značilnosti Discipline Faze in poti Vloge Izdelki Pristopi k prilagoditvi in inačice Dopolnilna ogrodja ali procesi Podpora orodij ZAKLJUČEK VIRI vii

9 KAZALO SLIK SLIKA 1: SCENARIJI PRILAGAJANJA PROCESNEGA OGRODJA SLIKA 2: EVOLUCIJA RUP SLIKA 3: ORODJE RMC IN BAZA ZNANJA RUP SLIKA 4: OGRODJE RUP SLIKA 5: ITERACIJE PRIREJENO PO SLIKA 6: OSNOVNI ELEMENTI OGRODJA RUP SLIKA 7: KONCEPTUALNI MODEL KLJUČNIH KONCEPTOV SLIKA 8: ŽIVLJENJSKI CIKEL TEHNOLOŠKIH REŠITEV PODJETJA MICROSOFT SLIKA 9: EVOLUCIJA OGRODJA MSF SLIKA 10: MSF FOR AGILE SOFTWARE DEVELOPMENT SLIKA 11: MSF DRUŽINSKO DREVO SLIKA 12: MSF MODEL SKUPINE SLIKA 13: MODEL OBVLADOVANJA SLIKA 14: IZDAJE OZNAČENE Z VERZIJO viii

10 KAZALO TABEL TABELA 1: NIVOJI NADALJEVALNE IN STOPENJSKE PREDSTAVITVE MODELA CMMI... 8 TABELA 2: ATRIBUTI PROCESNIH OGRODIJ TABELA 3: NAPOTKI OGRODJA RUP TABELA 4: GLAVNE IN OBROBNE VLOGE TER IZDELKI DISCIPLIN OGRODJA RUP TABELA 5: CILJI KAKOVOSTI TABELA 6: GLAVNI IZDELKI POTI IZGRADNJE KLASIFICIRANI PO VLOGAH TABELA 7: PRIMERJAVA DISCIPLIN OGRODJA RUP Z DISCIPLINAMI IN VLOGAMI OGRODJA MSF TABELA 8: ŠTEVILO VLOG OGRODIJ RUP IN MSF TABELA 9: KONCEPTUALNA PRESLIKAVA VLOGE PRODUKTNI VODJA V VLOGE OGRODJA RUP TABELA 10: INAČICE OGRODIJ RUP IN MSF TABELA 11: PODPORNA ORODJA OGRODIJ RUP IN MSF ix

11 UPORABLJENE KRATICE CASE CMMI EPF HTML IT JAD IS RMC MOF MSF SOA SOMA SPEM SPICE UMA Computer Aided Software Engineering Capability Maturity Model Integration Eclipse Process Framework Hyper Text Merkup Language Information Technology Joint Application Development Information System Rational Method Composer Microsoft Operation Framework Microsoft Solution Framework Service Oriented Architecture Service Oriented Modeling and Architecture Software Process Engineering Metamodel Software Process Improvement and Capability Determination Unified Method Architecture x

12 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 1

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

14 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]. 3

15 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, 4

16 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 5

17 č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 , Software Process Improvement and Capability Determination (SPICE) ter Združeni zrelostni zmožnostni model. Slednji bo opisan v naslednjem poglavju. 6

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

19 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]? 8

20 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]. 9

21 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 ITorganizaciji 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] 10

22 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]. 11

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

24 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 13

25 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 Kategorizacija Komercialnost / podjetje Dokumentacija (HTML) Podporna orodja za prilagajanje RUP 7.0 MSF 4.0 Open UP 1.5 RUP SOMA 2.4 generično procesno ogrodje generično procesno ogrodje procesno ogrodje da / IBM da / Microsoft ne / odprta rešitev Da, privzeta Ne, knjiga [7]. Da, Wiki spletna spletna stran, stran. generirana s podpornim orodjem. Rational Method Composer v.7.5 ne Eclipse Process Framework Composer v procesno ogrodje da / IBM Da, privzeta spletna stran, generirana s podpornim orodjem. Rational Method Composer v.7.5 MSF Agile Software Development 4.2 procesno ogrodje da / Microsoft Modelirni jezik UML ni opisan UML UML ni opisan Pokritost celotnega da da da da da življenjskega cikla Različni pogledi da da da da da Da, procesni napotki agilne šablone v podpornem orodju (Visual Studio 2008 Team System Suite). Visual Studio 2008 Team System Suite, Visual Studio 2008 Team Foundation Server 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 14

26 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 15

27 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]. 16

28 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]. 17

29 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 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] 18

30 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] 19

31 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 20

32 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] 21

33 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] 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 22

34 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 23

35 (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 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]. 24

36 Tabela 3: Napotki ogrodja RUP [4] VRSTA NAPOTKA OPIS Kontrolni seznam (angl. Checklist) Koncept (angl. Concept) Primer (angl. Example) Smernica (angl. Guideline) Praksa (angl. Practice) Poročilo (angl. Report) Ponovno uporabno sredstvo (angl. Reausable Asset) Procesna karta (angl. Roadmap) Podporno gradivo (angl. Supporting Material) Šablona (angl. Template) Usmeritve (angl. Whitepaper) Mentorji za orodja (angl. Tool Mentor) 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. 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). Prikazuje praktično uporabo izdelkov ali opravil. Dopolni referenciran element z bolj podrobnimi informacijami. Še posebej je uporaben za začetnike, ki načeloma potrebujejo za dokončanje dela dodatno pomoč. Opisuje jasne, preizkušene strategije, ki so uporabne v različnih situacijah. Opisuje standarde za vnaprej definirane oblike ali razporeditve informacij kot tudi informacij, pridobljenih iz izdelkov. Koristni element, ki zagotavlja vrednost in kakovost. Rešitev je ponovno uporabno sredstvo, če zagotavlja vrednost v različnih situacijah v določenem kontekstu. Priključena aktivnostim z namenom vodenja uporabnikov skozi kompleksen proces od začetka do konca. Vsak zahtevan napotek, ki ni skladen z nobenim drugim opisom napotka v tej tabeli. Zagotavlja vnaprej definirano strukturo izdelkom in s tem zagotavlja konstistenco med istovrstnimi izdelki. 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. 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 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]. 25

37 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 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 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 26

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

39 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 ITreš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, 28

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

41 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 30

42 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, 31

43 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, 32

44 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 33

45 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 34

46 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]. 35

47 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 36

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

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

50 Tabela 4: Glavne in obrobne vloge ter izdelki disciplin ogrodja RUP [4, 14, 16] DISCIPLINE Poslovno modeliranje Zajemanje zahtev Analiza in načrtovanje Implementacija GLAVNE VLOGE analitik poslovnega procesa, poslovni načrtovalec, poslovni arhitekt sistemski analitik, popisovalec zahtev arhitekt programske opreme, sistemski analitik, načrtovalec, načrtovalec uporabniškega vmesnika, načrtovalec podatkovne baze implementator, povezovalec, arhitekt programske opreme OBROBNE VLOGE tehnični pregledovalec arhitekt programske opreme, tehnični pregledovalec načrtovalec podatkovnega modela, tehnični pregledovalec, načrtovalec testiranja tehnični pregledovalec GLAVNI IZDELKI dokument poslovne arhitekture, model poslovnih primerov uporabe, model poslovnega načrtovanja, ocena ciljne organizacije vizija, slovar, načrt upravljanja, softverske zahteve, specifikacija zahtev, zahteve deležnikov, zgodborisi, dodatne specifikacije, model primerov uporabe, zahtev 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 implementacijski elementi, podsistem implementacije, načrt integracije gradenj Testiranje Upravljanje konfiguracij in sprememb Vodenje projektov Okolje vodja testiranja, analitik testiranja, načrtovalec testiranja, preskuševalec upravitelj konfiguracije, upravitelj nadzora sprememb vodja projekta, pregledovalec upravljanja procesni inženir, sistemski administrator, strokovnjak za orodja načrtovalec, implementator, procesni inženir povezovalec, vsaka vloga, vodja projekta, analitik testiranja pregledovalec, usklajevalec pregledov analitik poslovnega procesa, sistemski analitik, načrtovalec uporabniškega vmesnika, arhitekt programske opreme, tehnični pisar 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 zahteva za spremembo, plan upravljanja konfiguracije, repozitorij projekta, delovni prostor poslovni primer, plan razvoja programske opreme, plan iteracij, zapisnik pregleda, seznam tveganj, seznam spornih zadev, ocenitev statusa, delovni nalog, plan namestitve proces razvoja, razvojni primer, smernice prilagojene projektu, predloge prilagojene projektu, razvojna infrastruktura, ocenitev organizacije razvoja, navodila za izdelavo priročnikov 39

51 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 40

52 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] 41

53 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 / MSF 1.0 MSF 2.0 MSF 2.5 MSF 3.0 MSF 4.0 uvedba discipline razvoja rešitev vpeljava principov za: razvoj aplikacij načrtovanje komponent uvedbo infrastrukture združena skupinski in procesni model spremembe v disciplini upravljanja s tveganji povezava med MSF in MOF 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. 42

54 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] 43