Rational Unified Process

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

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.

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.

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.

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.

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.