Rational Unified Process

Šiam straipsniui ar jo daliai trūksta išnašų į patikimus šaltinius. Jūs galite padėti Vikipedijai pridėdami tinkamas išnašas su šaltiniais.

RUP (angl. Rational Unified Process) – kartotinio programinės įrangos kūrimo metodika, sukurta įmonės Rational Software, nuo 2003 m. priklausančios IBM.

RUP nėra pavienis procesas, tai apdatuotas procesų karkasas, tinkantis programinės įrangos kūrėjų organizacijoms ar komandoms, kurios pagal poreikį pasirenka tam tikrus elementus iš procesų. Produktas apima tarpusavyje susijusias žinias, grįstas artefaktais ir daugelio skirtingų veiklų detalizuotą aprašymą. RUP įtrauktas į IBM Rational Method Composer produktą, kuris leidžia derinti procesus. Suvienytas procesas buvo sukurtas, kad apimti viešą dalykinės srities procesą (žinomą kaip jungtinis procesas) ir detalesnę specifikaciją, žinomą kaip Rational Unified Process, kurią galima pateikti kaip komercinį produktą.

Istorija

Rational Process prasidėjo nuo spiralės modelio, kurį pasiūlė Barry Boehm. Racionalus metodas buvo sukurtas Rational Software 1980–1990 m. 1995 jį įsigijo Švedijos kompanija Objectory AB. RUP buvo rezultatas sujungus Rational Method ir Objectory procesą, kurį sukurė Ivar Jacobson. Po sujungimo pirmas rezultatas buvo Rational Objectory Process, skirtas vartotojų atpratinimui nuo Rational Rose įrankio. Pirma RUP‘o versija 5.0 realizuota 1998 m. Pagrindinis kūrėjas Philippe Kruchten. Naujausia RUP (7.0) versija išleista 2005 lapkritį.

Šeši principiniai kūrimo raktai

RUP grįstas šešiais raktiniais principais:

• Adaptuoti procesą;
• Subalansuoti tarpinius prioritetus;
• Glaudžiai bendradarbiauti tarp komandų;
• Iteratyviai pateikti vertes;
• Tobulinti abstrakcijos lygį;
• Tęstinai fokusuotis į kokybę.

Adaptuoti procesą

Organizacija privalo teisingai prisitaikyti procesą savo poreikiams, pvz., projekto valdymą, projekto dydį, reguliavimo mechanizmus, kurie apibrėžia formalumo lygį projekte. RUP pateikia konfigūracinius proceso šablonus mažiems, vidutiniams ir dideliems projektams, kurie gali būti naudojami lengvesniam adaptavimui. Proceso tvarka turi atspindėti RUP fazių tikslus. Adaptuojant procesą taip pat remiamas tęstinis proceso gerinimas organizacijoje.

Subalansuoti tarpinius prioritetus

Tai apiima verslo tikslus ir tarpininkų poreikius. Jie dažnai konkuruoja ir konfliktuoja ir tai privalo būti subalansuota.

Bendradarbiavimas tarp komandų

Programinės įrangos inžinerija yra komandinis darbas su didele tarpininkų aibe ir visi tarpininkai turi būti išgirsti. Augant globaliai išskirstyto kūrimo poreikiui bendradarbiavimas realizuojamas per modernias komunikacijos priemones. Bendradarbiavimas nėra ribojamas pagal reikalavimus, bet apima pasikeitimą metrikomis, testavimo rezultatais, projektų planais. Tai atitinka RUP projektą, kuris realizuojamas iteratyviniu principu.

Iteratyvus verčių demonstravimas

Projektas yra realizuotas, net jeigu kalbama tik apie vidų, kai yra tobulėjimas iteratyviniu būdu. Gerinimas, kuris apima paskutinės iteracijos reikšmes, yra naudojamas projekto progreso matavimui. Tas didėjimas taip pat naudojamas skatinti grįžtamąjį ryšį iš tarpininkų apie projekto kryptį. Tai leidžia projektams prisitaikyti prie pasikeitimų, kurie priklauso nuo grįžtamojo ryšio. Iš kitos pusės tarpininkai gali daryti poveikį kūrimo pastangoms projekto vykdymo metu. Iteratyvinio kūrimo kombinacija ir koncentravimasis į rizikas RUP‘e leidžia iteratyviai vertinti projekto riziką.

Abstrakcijos lygis

Šis principinis raktas motyvuoja naudoti pakartotinai panaudojamus dalykus, tokius kaip programinės įrangos šablonus, 4gl ar karkasus. Didesnis abstrakcijos lygis sudaro galimybę diskutuoti apie skirtingus architektūros lygius. Tai gali būti perteikiama vizualiai, pvz., UML.

Tęstinė kokybė

Kokybės patikrinimas nėra tik iteracijos pabaigoje, bet tęstinis per veiklas projekte, dažnai atliekamas kasdien. Testų scenarijaus (skriptai) automatizavimas padeda susitvarkyti su didėjančių testų kiekiu.

Projekto gyvavimo ciklas

RUP‘o gyvavimo ciklas yra spiralės modelio tipo. Tai atliekama per turinio elementų sudėjimą į dalinai surūšiuotą seką. Todėl RUP gyvavimo ciklas yra kaip darbų suskaldymo struktūra, kuri gali būti derinama, kad pritaikyti prie specifinių projekto poreikių. RUP gyvavimo ciklas organizuoja užduotis į fazes ir iteracijas. Projektą sudaro keturios fazės:

• Inspekcijos;
• Tyrimo;
• Kūrimo;
• Perdavimo.

Inspekcijos fazė

Šioje fazėje yra nustatoma verslo aplinka, kuri apima verslo kontekstą, sėkmės faktorius (laukiamą biudžetą, pripažinimą rinkoje ir t.t) ir finansines prognozes. Kad užbaigti verslo analizę, sukuriamas pagrindinis užduočių modelis, projekto planas, pradinis rizikų įvertinimas ir projekto aprašymas (pagrindiniai projekto reikalavimai, apribojimai ir esminės savybės). Atlikus šį darbą, projektas patikrinamas pagal šiuos kriterijus:

• Tarpininkų pritarimas apimties ir kainos/tvarkaraščio įvertinimui;
• Reikalavimų supratimas, kaip įrodymas per užduočių modelį;
• Atitikimas kainos/vykdymo plano, prioritetų, rizikų ir kūrimo proceso;
• Gilumas ir platumas bet kokio architektūrinio prototipo, kuris buvo sukurtas;
• Realizacija pagrindinių gairių, kuriomis bus lyginamos realios išlaidos su planuotomis.

Jeigu projektas nukrypsta nuo kontrolinių taškų, vadinamų gyvavimo ciklo tikslo kontroliniais taškais, kad būtų geriau pasiekiami tikslai, jis gali būti nutrauktas arba gali būti pakartotas po fazės pataisymo.

Tyrimo fazė

Šioje fazėje projektas įgauna tikrąją savo formą. Atliekama probleminės srities analizė ir projekto architektūra įgauna pagrindines formas. Fazė turi atitikti gyvavimo ciklo architektūros kontrolinius taškus, kurie turi būti:

• Užduočių modelis, kuriame identifikuotas užduočių modelis ir aktoriai bei sukurta dauguma aprašymų. Užduočių modelis turi būti užbaigtas ne mažiau kaip 80 % ;
• Programinės įrangos aprašymas programinės įrangos kūrimo procese;
• Vykdoma architektūra, kuri realizuoja užduočių modelį;
• Peržiūrėtas rizikų sąrašas;
• Sukurtas viso projekto planas;
• Prototipai, kurie akivaizdžiai sušvelnina kiekvieną identifikuotą riziką.

Jei projektas negali patenkinti šių reikalavimų, vis dar yra laiko nutraukti arba perplanuoti. Po šios fazės projektas pereina į aukštos rizikos operacijas, kur pakeitimai yra daug sudėtingesni. Dalykinės srities analizės esmė yra sistemos architektūra.

Kūrimo fazė

Šioje fazėje pagrindinis dėmesys skiriamas komponentų kūrimui ir kitoms sistemos savybėms. Tai fazė, kurioje kuriamas kodas. Dideliuose projektuose, gali būti keletas kūrimo iteracijų, tam kad suskaldyti užduočių modelį į valdomus segmentus, kuriuose galima sukurti demonstracinius prototipus. Ši fazė sukuria pirmą programinės įrangos versiją.

Perdavimo fazė

Perdavimo fazėje produktas perduodamas galutiniams vartotojams. Šioje fazėje yra tokios veiklos kaip galutinių vartotojų mokymai ir palaikymas, sistemos beta testavimas. Produktas patikrinamas ar atitinka kokybės lygį. Jei neatitinka kokybės lygio, standartų arba galinių vartotojų poreikių, visas ciklas pakartojamas iš naujo.

Disciplinos ir darbų sekos

RUP yra pagrįstas eile elementų, aprašančių kas turi būti padaryta, kokie įgūdžiai būtini, paaiškinama žingsnis po žingsnio kaip turi būti siekiami specifiniai kūrimo tikslai. Pagrindiniai kūrimo elementai yra:

• Rolės (kas?) – rolė apibrėžia aibę įgūdžių, kompetencijų ir atsakomybių.
• Darbo produktas (kas bus padaryta?) – darbo produktas tai yra kažkas, kas gaunama atlikus užduotį, įskaitant visus dokumentus, modelius, kurie atsirado kūrimo metu.
• Užduotis (kaip?) – užduotis apibrėžia darbo vienetą, kuris priskirtas tam tikrai rolei ir generuoja prasmingą rezultatą.

Kiekvienos iteracijos metu užduotys suskirstomos į devynias disciplinas: Inžinerinės disciplinos:

• Verslo modeliavimas;
• Reikalavimai;
• Analizė ir kūrimas;
• Įgyvendinimas;
• Testavimas;
• Pristatymas.

Palaikymo disciplinos:

• Konfigūracija ir pakeitimų valdymas;
• Projekto valdymas;
• Aplinka.

Verslo modeliavimo disciplina

Organizacijos tampa labiau priklausomos nuo informacinių sistemų. Todėl informacinių sistemų inžinieriams būtina žinoti kaip taikomosios programos tiks organizacijai. Verslas investuoja į IT tada, kai jie supranta konkurencinį pranašumą ir naudą, kurią duoda IT technologijos. Verslo modeliavimo tikslas yra užtikrinti geresnį bendradarbiavimą tarp verslo inžinierių ir programinės įrangos inžinierių. Tai reiškia, kad programinės įrangos inžinieriai privalo suprasti organizacijos struktūrą ir dinamiką, esamas problemas organizacijoje ir galimus sprendimus, patobulinimus. Jie taip pat turi užtikrinti gerą susikalbėjimą tarp organizacijos, jos klientų, galutinių vartotojų ir kūrėjų. Verslo modeliavimas išaiškina kaip galima apibrėžti organizacijos viziją ir kaip tą viziją naudoti apibrėžiant procesus, roles ir atsakomybes.

Reikalavimų disciplina

Šios disciplinos tikslas yra apibrėžti ką sistema turėtų daryti ir leisti kūrėjams sutarti su klientu dėl apibrėžimo. Kad tai pasiekti, analitikas renka, organizuoja ir dokumentuoja reikiamus funkcionalumus.

Analizė ir kūrimas

Šios disciplinos tikslas yra parodyti kaip sistema bus realizuota diegimo fazėje. Tikslas yra sukurti sistemą, kuri:

• Specifinėje aplinkoje atlieka užduotis ir funkcijas, specifikuotas užduočių modelio aprašyme;
• Tenkina visus reikalavimus;
• Lengvai keičiama, kai keičiasi funkciniai reikalavimai.

Analizė ir projektavimas duoda projektavimo modelį ir papildomai analizės modelį. Projektavimo modelis tarnauja kaip kodo modelio abstrakcija. Projektavimo modelis susideda iš klasių, sudėtų į paketus ir posistemes, su gerai apibrėžtais interfeisais, pateikiančiais kas bus realizacijoje. Tai taip pat apima apibrėžimus kaip objektai bendradarbiauja atlikdami užduotis iš užduočių modelio.

Įgyvendinimo disciplina

Tikslai:

• Apibrėžti kodo organizaciją realizacijos terminais, posistemės organizuojamos per sluoksnius;
• Realizuoti klases ir objektus komponentų terminais (išeities bylos, dvejetainės, vykdomos ir kitos);
• Testuoti sukurtus komponentus kaip vienetus;
• Integruoti į vykdomą sistemą.

Procesas apibrėžia kaip galima pakartotinai panaudoti egzistuojančius komponentus ar įdiegti naujus komponentus su jau gerai apibrėžtomis atsakomybėmis. Tai palengvina sistemos palaikymą ir didina pakartotinį panaudojamumą.

Testavimo disciplina

Jos tikslai:

• Verifikuoti sąveiką tarp objektų;
• Verifikuoti teisingą visų komponentų integravimą;
• Verifikuoti reikalavimų korektiška realizaciją;
• Identifikuoti ir užtikrinti, kad defektai aptikti ir pataisyti iki programinės įrangos pristatymo vartotojui;
• Užtikrinti, kad visi defektai yra ištaisyti, ištestuoti ir uždaryti.

RUP siūlo iteratyvų priartėjimą, kuris reiškia, kad testavimas vyksta viso projekto metu. Tai leidžia surasti defektus taip anksti, kaip tai tik įmanoma, kas žymiai sumažina klaidų taisymo kainą. Testai vykdomi keturiose dimensijose: patikimumo, funkcionalumo, aplikacijų vykdymo, ir sistemos vykdymo. Kiekvienai iš šių dimensijų, procesas apibrėžia kaip reikia atlikti testavimo planavimą, kūrimą, realizavimą, vykdymą ir vertinimą.

Pristatymo disciplina

Šios disciplinos tikslas sėkmingai pagaminti galutinę produkto versiją ir pristatyti programinę įrangą galiniams vartotojams. Tai apima platų veiklų ratą:

• Galutinės patikrintos versijos pagaminimą;
• Pakavimą;
• Programinės įrangos paskirstymą;
• Programinės įrangos įdiegimą;
• Pagalbos teikimą ir vartotojų konsultavimą.

Pristatymo veiklos daugiausia susijusios su perdavimo faze, dauguma veiklų turi būti įtrauktos į ankstesnes fazes, kad paruošti pristatymą konstravimo fazės pabaigoje. RUP‘o pristatymo ir aplinkos darbų sekos yra mažiau detalios nei, kad kitos darbų sekos.

Konfigūracijos ir pakeitimų valdymo disciplina

Ši disciplina sudaryta iš 3 sričių:

• Konfigūracijos valdymas;
• Pakeitimų užklausų valdymas;
• Statuso ir matavimų valdymas.

Konfigūracijos valdymas

Konfigūracijos valdymas atsakingas už sisteminį produkto struktūrizavimą. Artefaktai, tokie kaip dokumentai ir modeliai, turi būti kontroliuojami pagal versijas ir visi pakeitimai turi būti prieinami ir atsekami. Taip pat sekamos priklausomybės tarp artefaktų taip, kad atitinkami straipsniai būtų keičiami kai tik atliekamas pakeitimas.

Pakeitimų užklausų valdymas

Sistemos kūrimo metu atsiranda daug artefaktų su keletu versijų. CRM seka visus pakeitimus.

Būsena ir matavimai

Pakeitimų užklausos turi tokias būsenas kaip nauja, užfiksuota, patvirtinta, priskirta, užbaigta. Pakeitimų užklausos taip pat turi atributus, tokius kaip pagrindinė priežastis, prigimtis, prioritetas. Šie atributai ir būsenos yra kaupiami duomenų bazėje, kad būtų galima sekti projekto progresą. Rational turi priemonę, vadinamą ClearQuest, pakeitimų užklausoms valdyti.

Projekto valdymo disciplina

Projekto valdymas RUP‘e pasireiškia per du lygius. Yra stambus padalinimas, fazių planas, kuris apibrėžia einamąjį projektą, ir serija detalių iteracijų planų, kurie apibrėžia kiekvieną iteraciją. Ši disciplina pagrinde akcentuoja tik svarbius iteratyvaus kūrimo proceso aspektus:

• Rizikų valdymas;
• Iteracijos planavimas per visa programinės įrangos kūrimo ciklą ir konkrečios atskiros iteracijos;
• Iteratyvaus projekto ir metrikų progreso stebėjimas.

Tačiau, ši disciplina neapima visų projekto valdymo aspektų, pvz.:

• Žmonių valdymas: samdymas, mokymas, treniravimas;
• Biudžeto valdymas: apibrėžimas, fiksavimas;
• Kontrakto valdymas su tiekėjais ir užsakovais.

Projekto valdymo disciplina apiima dalį planų ir artefaktų, kurie naudojami kontroliuoti projektui ir stebėti jo vykdymą. Tokie planai yra:

• Fazės planas;
• Iteracijos planas.

Fazės planas

Kiekviena fazė traktuojama kaip projektas, kontroliuojamas ir matuojamas programinės įrangos kūrimo plano, kuris sudarytas iš:

• Matavimų plano, kuris apibrėžia matavimų tikslus, metrikas;
• Rizikų valdymo plano, kuris detalizuoja kaip valdyti rizikas susijusias su projektu. Detalizuojamos rizikų valdymo užduotys, kurios bus vykdomos, priskirtos atsakomybės, ir kiti papildomi resursai, reikalingi rizikų valdymo veiklai. Mažesniuose projektuose, šis planas gali būti sujungtas su programinės įrangos kūrimo planu.
• Rizikų sąrašo, kuris yra surūšiuotas žinomų rizikų sąrašas, surūšiuotas rizikos svarbos mažėjimo tvarka ir susietos su specifiniais sušvelninimo arba išvengimo veiksmais;
• Problemų sprendimo plano, kuris apibrėžia procesus, naudojamus ataskaitoms, analizuoti ir spręsti problemas, kurios atsiranda vykdant projektą;
• Produkto tinkamumo plano. Jis apibrėžia kaip užsakovas vertins produktą. Jame pateikiami vertinimo kriterijai ir identifikuojamos produkto tinkamumo patvirtinimo užduotys (įskaitant testus, kurie turi būti atlikti), kurios turi būti atliktos, paskirstytos atsakomybės ir reikalingi resursai. Mažesniuose projektuose šis planas gali būti sujungtas su programinės įrangos kūrimo planu.

Iteracijos planas

Iteracijos planas yra detalus ir jame apibrėžiamos iteracijos veiklos ir užduotys, priklausomybės tarp užduočių konkrečioje iteracijoje. Tipiškai yra du iteracijos planai bet kuriuo laiko momentu:

• Esamos iteracijos planas;
• Sekančios iteracijos planas.

Kad sudaryti iteracijos planą reikia:

• Projekto plano;
• Esamo projekto statuso;
• Scenarijų arba užduočių modelių sąrašo, kurie turi būti užbaigti iteracijos pabaigoje;
• Rizikų sąrašo, kuris turi būti peržiūrėtas iteracijos pabaigoje;
• Pakeitimų sąrašo, kuris turi būti realizuotas produkte;
• Klasių ar paketų sąrašo, kuris turi būti pilnai realizuotas;

Darbo produktas (artefaktas)

IBM pakeitė sąvoką „artefaktas“ į sąvoką „darbo produktas“. Darbo produktas naudojamas:

• Iteracijos įvertinimui, kiek vertinimo kriterijai pasiekti, išmoktos pamokos, atlikti pakeitimai;
• Projekto vertinimui – apima resursus, procesus, produktą;
• Periodinio statuso vertinimui, kuris pateikia išimčių valdymo mechanizmą per visą projekto gyvavimo ciklą, kad užtikrinti visų išimčių sinchronizaciją ir nuoseklumą.
• Darbo užsakymui, kuris yra projekto vadovo priemonė komunikuoti, kas bus daroma ir kada.
• Problemų sąrašui, tai yra būdas fiksuoti ir sekti problemas, išimtis, anomalijas ir kitus dalykus reikalaujančius daugiau dėmesio.

Aplinkos disciplina

Aplinkos disciplinos fokusuojasi į veiklas, būtinas proceso priderinimui prie projekto. Apibrėžia veiklas, reikalingas gairėms projekto palaikymui sukurti. Šių veiklų tikslas yra parūpinti programinės įrangos kūrimo bei programinės įrangos aplinkos kūrimo organizavimą, abu procesus ir įrankius, kurie bus naudojami komandos kūrimui. Išskiriami trys pagrindiniai žingsniai. Projekto aplinkos paruošimui reikia:

• Apibrėžti kaip projekte bus naudojamas priderintas kūrimo procesas;
• Sukurti kūrimo aplinką apibrėžiant nuokrypius nuo pagrindinio proceso;
• Apibrėžti artefaktų pasirinkimą pagal reikalavimus ir laiką;
• Specifinio inventoriaus paruošimas, tokio kaip gairės ir šablonai, atitinkantys kūrimo būdą;
• Sukurti sąrašą įrankių, kurie bus naudojami kūrime.

Aplinkos paruošimas iteracijai. Šių darbų tikslas paruošti ir užtikrinti projekto aplinką sekančiai iteracijai. Tai apima procesus ir įrankius. Pagrindinis akcentas į:

• Sukomplektuoti kūrimo aplinką, tai yra pasirengti iteracijai;
• Paruošti ir, jei reikia, priderinti įrankius iteracijai;
• Verifikuoti įrankius;
• Paruošti aibę šablonų ir gairių, palaikančių projektų artefaktų kūrimą iteracijoje;
• Įsitikinti, kad pakeitimai atlikti ir tinkamai pateikti projekto nariais.

Aplinkos palaikymas iteracijos metu palaiko kūrėjus, įrankių ir procesų naudojimą. Tai apima reikiamos programinės įrangos įdiegimą bei užtikrinimą, kad teisingai veikia techninė ir tinklų įranga.

IBM Rational Method Composer produktas

IBM Rational Method Composer yra įrankis skirtas procesų konfigūravimui, autorizavimui, peržiūrėjimui ir darymui. Daugiau galima sužinoti IBM Rational MEthod Composer ir atviro platinimo versijoje Eclipse Process Framework.

Sertifikacija

2007 m. sausį buvo išleistas naujas RUP sertifikavimo egzaminas IBM Sertified Designer- Rational Unified Process 7.0, kuris pakeitė ankstesnį IBM Rational Certified Specialist- Rational Unified Process.

Papildomam skaitymui

• IBM White paper „Rational Unified Process: Best practices for software development teams“, Last updated July 23, 2005 [1]
• Sandra Sergi Santos „Comparing the Rational Unified Process (RUP) and Microsoft Solutions Framework (MSF)“, First published: April 15, 2007 [2]
• Wolfgang Hesse „Dinosaur Meets Archaeopteryx? Seven Theses on Rational's Unified Process (RUP)“ // Proc. CAiSE'98/LFIP 8.1 Int. Workshop on Evaluation of Modelling Methods in System Analysis and Design (EMMSAD'01), Interlaken 2001 [3]
• Jorge A. Osorio, Michel Chaudron, Werner Heijstek „Moving From Waterfall to Iterative Development - An Empirical Evaluation of Advantages, Disadvantages and Risks of RUP“ // 37th Euromicro Conference on Software Engineering and Advanced Applications (SEAA 2011) Helsinki, Finland, 2011, DOI: 10.1109/SEAA.2011.69. [4]