RUP

Wikipediasta
Siirry navigaatioon Siirry hakuun
Tämä artikkeli käsittelee ohjelmistohankkeiden prosessikehystä. Lyhenne voi tarkoittaa myös valtiollista unitaarista yritystä. Katso RUP (täsmennyssivu).
RUP:in mukaan etenevän projektin vaiheet.

Unified Process (UP, suom. yhtenäistetty prosessi, myös Unified Software Development Process, suom. yhtenäistetty ohjelmistokehitysprosessi) on iteratiivisen ja inkrementaalisen ohjelmistokehityksen prosessikehys. Sen tunnetuin ja perusteellisimmin dokumentoitu versio on IBM Rational Unified Process (RUP), jonka kehitti Rational Software Corporation (IBM:n osasto vuodesta 2003 lähtien).

Unified Process ei ole itsenäinen prosessi vaan laajennettava kehys, joka tulee muokata vastaamaan organisaation tai projektin erityistarpeita. Rational:in yhtenäistetty prosessi eli RUP (Rational Unified Process, nimi juontuu prosessikuvauksen luoneen Rational Software Corporationin nimestä) on samalla tavoin muokattava kehys. Joskus muokatusta prosessikuvauksesta on vaikea sanoa onko se peräisin UP:stä vai RUP:sta, joten termejä käytetäänkin usein sekaisin.

Iteratiivisen ohjelmistokehitys-mallin vaiheet

Nimeä Unified Process käytetään usein korvaamaan nimeä Rational Unified Process, kun puhutaan yleisesti prosessista ja siihen tavallisimmin tehdyistä muokkauksista. Nimeä Unified Process käytetään usein myös siksi, että halutaan välttää mahdolliset tekijänoikeusloukkaukset, sillä Rational Unified Process ja RUP ovat IBM:n ja Intel:n tavaramerkkejä. Ensimmäinen prosessia kuvaileva kirja The Unified Software Development Process (ISBN 0-201-57169-2) julkaistiin vuonna 1999 (tekijöinä Ivar Jacobson, Grady Booch ja James Rumbaugh). Tämän jälkeen useat eri tekijät ovat julkaisseet kirjoja ja artikkeleita aiheesta käyttäen joko termiä Rational Unified Process (mikäli ovat liitoksissa IBM:n kanssa) tai Unified Process (mikäli eivät ole yhteydessä IBM:ään).

Neljä projektin elinkaaren vaihetta

[muokkaa | muokkaa wikitekstiä]

Rup vaiheita ja järjestyksiä

[muokkaa | muokkaa wikitekstiä]

Rup määrittelee projektin elinkaaren koostuvan neljästä vaiheesta. Nämä vaiheet sallivat, että prosessi voidaan esittää korkealla tasolla samanlailla kuin ’vesiputous’-mallin projekteissa voitaisiin esittää, vaikkakin perusolettamuksena avain prosessiin sijaitsee kaikkien eri vaiheiden kehityksen iteraatioissa. Myös, jokaisella vaiheella on tietty päämäärä lopussa, joka ilmaisee tavoitteen onnistuneen toteutuksen.

Voimaantulovaihe

Päätavoitteena on tutkia järjestelmää, lähtökohtana tarkistaa alustava kustannusarvio ja budjetti. Tässä vaiheessa yrityskonteksti, menestystekijät ja taloudellinen ennuste vahvistetaan. Täydennetäkseen nämä vaiheet luodaan peruskäyttötapausmalli, projektisuunnitelma, alustava riskiarviointi ja projektikuvaus. Kun nämä on toteutettu projekti arvioidaan ja tarkistetaan sen kannattavuus.

Kehittelyvaihe

Tämän vaiheen päätavoite on vähentää pahimpia havaittuja riskejä. Tässä vaiheessa projekti rupeaa ottamaan muotoa. Vaiheen aikana tehdään ongelma-alueiden analyysi, ja projektin arkkitehtuuri saa perusmuotonsa.

Rakennusvaihe

Päätavoite on rakentaa ohjelmisto. Tässä vaiheessa keskitytään suunnitellun järjestelmän komponenttien ja muiden ominaisuuksien kehittämiseen. Tässä vaiheessa tapahtuu valtaosa ohjelmoinnista.

Tämä vaihe tuottaa ensimmäisen ulkoisen julkaisun ohjelmistosta.

Muutosvaihe

Päätavoite on muuntaa järjestelmä kehitysasteelta tuotantoon ja tuoda se loppukäyttäjän saataville ja ymmärrettäväksi. Tämän vaihe sisältää loppukäyttäjän ja ylläpitäjien kouluttamisen ja järjestelmän testaamisen, jotta huomataan toteutuuko loppukäyttäjien odotukset.

Kuusi parasta tapaa

[muokkaa | muokkaa wikitekstiä]

RUPissa kuvattu Kuusi parasta tapaa on ohjelmistotuotannon malli, joka listaa kuusi ideaa joita tulisi seurata ohjelmistoprojektin suunnittelussa vikojen minimoimiseksi ja tuottavuuden parantamiseksi. Nämä tavat ovat:

Kehitä iteratiivisesti
On hyvä tietää kaikki vaatimukset etukäteen, mutta useimmiten tämä ei ole mahdollista. Useat ohjelmistotuotannon prosessit tähtäävät kustannusten minimointiin kehitysmallien avulla.
Hallinnoi vaatimuksia
Pidä aina käyttäjien asettamat vaatimukset mielessä.
Käytä komponentteja
Kehittyneen projektin ositus ei ole pelkästään suositeltavaa vaan itse asiassa välttämätöntä. Tämä mahdollistaa yksittäisten osioiden testaamisen ennen kuin ne liitetään suurempaan systeemiin. Koodin uudelleenkäyttö on myös suuri plussa ja on saavutettavissa helpommin olio-ohjelmoinnin avulla.
Suunnittele visuaalisemmin
Käytä kaavioita esittämään kaikkia tärkeitä komponentteja, käyttäjiä ja niiden vuorovaikutusta. "UML", eli Unified Modeling Language on työkalu, jonka avulla tästä tehtävästä saadaan helpompaa.
Valvo laatua
Tee testauksesta aina suuri osa projektia. Testauksesta tulee rankempaa projektin edetessä, mutta sen pitäisi silti olla tärkeä osa jokaisen ohjelmistotuotteen kehityksessä.
Hallinnoi muutoksia
Useat projektit luodaan usean tiimin avulla, tiimien sijainnin ja alustan vaihdellessa. Tämän takia on tärkeää pitää kirjaa systeemiin tehdyistä muutoksista. Versionhallinta on hyvä työkalu tässä.
  • Kroll, Per; Kruchten, Philippe (2003). The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. ISBN 0-321-16609-4.
  • Kruchten, Philippe (2004). The Rational Unified Process: An Introduction (3rd Ed.). ISBN 0-321-19770-4.
  • Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. ISBN 0-13-111155-8.
  • Scott, Kendall (2002). The Unified Process Explained. ISBN 0-201-74204-7.
  • Bergstrom, Stefan; Raberg, Lotta (2004). Adopting the Rational Unified Process: Success with the RUP. ISBN 0-321-20294-5.