Rational Unified Process -menetelmä ohjelmistotestauksessa

Rational Unified Process (RUP) -menetelmä käyttää suunnittelussaan oliosuuntautunutta lähestymistapaa, ja prosessien havainnollistamiseksi on suunniteltu ja dokumentoitu UML-merkintätapa (UML = Unified Modeling Language). Siinä käytetään kaupallisesti testattuja tekniikoita ja käytäntöjä.

Prosessia pidetään raskaana ja mieluiten sovellettavana suuriin kehitystiimeihin ja suuriin projekteihin, mutta koska se on laajalti muokattavissa, se voidaan sovittaa minkä tahansa mittakaavan projekteihin.

Kohtaista

Projektinhallintaan RUP(Rational Unified Process) -malli tarjoaa kurinalaisen ratkaisun, kuten ohjelmistokehitysorganisaatiossa hahmotellut tehtävät ja vastuut.

RUP (Rational Unified Process) on itsessään ohjelmistotuote. Se on modulaarinen ja automatisoitu, ja sen koko metodologiaa tukevat useat kehitystyökalut, jotka IBM on integroinut ja joita se myy ”Rational Suites” -nimellä.

Ohjelmistotekniikan kilpailumenetelmiin kuuluvat ”puhdasoppiset” (joita pidetään raskaina) ja ketterät (kevyet) menetelmät, kuten äärimmäinen ohjelmointi (Extreme Programming, XP-Extreme Programming), Scrum, FDD ja muut.

On olemassa tiettyjä ohjeita ja malleja, jotka on määritelty RUP:n tuotantosyklin henkilökunnalle: osa asiakasta ja sen johdon tekemä arvio projektin etenemisestä. Se auttaa kehittäjiä keskittymään projektiin.

Johdon vaatimukset

Tarkoituksenmukainen dokumentointi on olennaista missä tahansa laajamittaisessa projektissa; huomaa, että RUP:ssä kuvataan, miten dokumentoidaan toiminnallisuus, järjestelmän rajoitukset, suunnittelurajoitukset ja liiketoimintavaatimukset.

Käyttötapaukset ja skenaariot ovat esimerkkejä riippuvaisista prosessiartefakteista, joita on pidetty paljon tehokkaampina toiminnallisten vaatimusten tallentamisessa.

Komponenttipohjaisen arkkitehtuurin käyttö

Komponenttipohjaisen arkkitehtuurin avulla luodaan järjestelmä, joka on helposti laajennettavissa, mikä edesauttaa uudelleenkäyttöä ja ohjelmistojen intuitiivista ymmärtämistä. Komponentilla tarkoitetaan yleensä objektia oliokeskeisessä ohjelmoinnissa.

RUP tarjoaa systemaattisen tavan rakentaa tämäntyyppisiä järjestelmiä keskittymällä toteuttamiskelpoisen arkkitehtuurin tuottamiseen projektin alkuvaiheessa eli ennen resurssien sitomista laajamittaisesti.

Tässä tarkoitetut komponentit sisältyvät yleensä jo olemassa oleviin infrastruktuureihin. Näitä infrastruktuureja ovat esimerkiksi CORBA sekä Component Object Model (COM).

Visuaalisten ohjelmistomallien käyttö RUP-mallissa

Abstrahoimalla koodin ohjelmoinnista ja esittämällä sen graafisten rakennuspalikoiden avulla RUP voi olla tehokas tapa saada yleiskuva ratkaisusta.

Visuaalisten mallien käyttö voi myös mahdollistaa sen, että henkilöt, joilla ei ole yhtä teknistä profiilia (kuten asiakkaat), ymmärtävät paremmin tietyn ongelman ja voivat siten osallistua paremmin koko projektiin.

UML-mallinnuskielestä on tullut alan standardi projektien esittämiseen, ja sitä käytetään laajalti RUP:ssä!

Tiedä lisää: Lue Ketterän testauksen eksklusiivisista yksityiskohdista

Ohjelmiston laadun tarkistaminen

Se ei varmista ohjelmiston laatua on yleisin epäonnistuminen kaikissa tietokonejärjestelmähankkeissa. Yleensä ajatellaan ohjelmiston laatua projektien valmistumisen jälkeen tai laatu on eri tiimin kehitystiimin vastuulla.

Muutosohjelmistojen hallinta ja valvonta

Muutosohjelmistojen hallinta ja valvonta

Muutosten olemassaolo on kaikissa ohjelmistoprojekteissa väistämätöntä. RUP määrittelee menetelmät muutosten hallintaan ja seurantaan. Koska pieni muutos voi vaikuttaa sovelluksiin täysin arvaamattomilla tavoilla, muutosten hallinta on olennaisen tärkeää projektin onnistumisen kannalta.

RUP (Rational Unified Process)määrittelee myös työ- ja tietoturva-alueet, jotka takaavat ohjelmoijalle sen, että toisessa järjestelmässä tehdyt muutokset eivät vaikuta omaan järjestelmään.

RUP-metodologian vaiheet

Niin pitkälle nämä suuntaviivat ovat yleisluontoisia ohjeita, joita noudattaen mennään läpi koko projektin elinkaaren. Vaiheet (ks. alla oleva kuva) osoittavat projektin painotuksen tietyllä hetkellä. Projektin ajallisen ulottuvuuden kuvaamiseksi RUP jakaa projektin neljään eri vaiheeseen:

Aloittaminen tai suunnittelu: järjestelmän laajuuden painottaminen;

Valmistelu: arkkitehtuurin painottaminen;

Rakentaminen: kehitystyön painottaminen;

Transitio: sovelluksen painottaminen.

RUP perustuu myös 4 P:hen:

• Ihmiset
• Suunnittelu
• Tuote
• Prosessi

Kerrokset koostuvat iteraatioista. Iteraatiot ovat aikaikkunoita; iteraatiot ovat määritelleet termin, koska vaiheet ovat objektiivisia.

Kaikki vaiheet tuottavat artefakteja. Niitä käytetään seuraavassa vaiheessa ja ne dokumentoivat projektin ja mahdollistavat paremman seurannan.

Suunnitteluvaihe

Suunnittelu- tai aloitusvaihe sisältää työnkulut, jotka ovat välttämättömiä, jotta asianomaiset osapuolet – sidosryhmät – voivat sopia projektin tavoitteista, arkkitehtuurista ja suunnittelusta. Jos näillä toimijoilla on hyvä tietämys, ei ole tarpeen analysoida. Muussa tapauksessa tarvitaan tarkempaa analyysia.

Tässä vaiheessa järjestelmän olennaiset vaatimukset muutetaan käyttötapauksiksi. Tavoitteena ei ole sulkea niitä lainkaan, vaan vain ne, jotka ovat välttämättömiä mielipiteen muodostamiseksi.

Vaihe on yleensä lyhyt, ja sen avulla määritellään, onko projektia mahdollista jatkaa, ja määritellään viimeisen vaiheen riskit ja kustannukset. Prototyyppi voidaan tehdä asiakkaan hyväksyttäväksi. Kuten RUP:ssä mainitaan, ihanteellista on suorittaa iteraatioita, joiden määrä ja tavoitteet on määriteltävä hyvin.

Elaborointivaihe

Vaiheessa valmistaudutaan järjestelmän suunnitteluun, täydennyksenä käyttötapausten kartoitukselle ja/tai dokumentoinnille, järjestelmän arkkitehtuurin eteen, tarkastellaan projektin liiketoimintamallia ja aloitetaan käyttöoppaan version laatiminen. Yksi on hyväksyttävä: Tuotekuvaus (lisäys + integrointi) on vakaa; hankesuunnitelma on luotettava? Kustannukset ovat tukikelpoisia?

Rakennusvaihe

Rakennusvaiheessa aloitetaan ohjelmiston fyysinen kehitys, tuotantokoodit, alfatestit. Siirtymävaiheen alussa suoritetaan beta-testit.

Testit on hyväksyttävä, vakaat ja testiprosessit, ja järjestelmäkoodi on ”lähtötasoa”.

Siirtymävaihe

Tässä vaiheessa on ohjelmiston toimittaminen (”käyttöönotto”), jossa toteutetaan käyttöönotto- ja toimitussuunnitelmaa, seurantaa ja ohjelmistojen laatua. Tuotteet (julkaisut, versiot) aiotaan toimittaa, ja sijoittaa asiakastyytyväisyys. Tässä vaiheessa tapahtuu myös käyttäjien kouluttaminen.

RUP (Rational Unified Process) -metodologian kurinalaisuudet

Liiketoimintamallinnuksen kurinalaisuus

Organisaatiot ovat yhä riippuvaisempia tietoteknisistä järjestelmistä, joten tietojärjestelmäinsinöörien on ehdottomasti tiedettävä, miten sovellukset integroidaan organisaation kehittämiseen. Yritykset investoivat tietotekniikkaan, joka ymmärtää teknologian tuottaman lisäarvon tuoman kilpailuedun.

Liiketoimintamallinnuksen tavoitteena on ensin luoda parempi ymmärrys ja kommunikaatio liiketoimintatekniikan ja ohjelmistosuunnittelun välille.

Liiketoiminnan ymmärtäminen tarkoittaa sitä, että ohjelmistosuunnittelijoiden on ymmärrettävä kohdeyrityksen (asiakkaan) rakennetta ja dynamiikkaa, organisaation tämänhetkisiä ongelmia sekä mahdollisia menetelmiä ja strategioita, joiden avulla ne voidaan korjata.

Toinen tärkeä näkökohta, jota ei saa aliarvioida, on se, että asiaankuuluvilla osapuolilla, kuten kehittäjillä sekä asiakkailla ja myös loppukäyttäjillä, on oltava selkeä ymmärrys organisaatiosta, ja tämän ymmärryksen tärkeä piirre on se, että sen on oltava yhteinen kaikille osapuolille.

Liiketoimintamallinnus selittää, miten kuvataan visio organisaatiosta, jossa järjestelmä toteutetaan, ja miten tätä visiota käytetään pohjana prosessien, toimintojen ja vastuiden kuvaamisessa.

Kurssin vaatimukset

Tässä kurssissa selitetään, miten saada pyyntöjä asianomaisilta osapuolilta (”asianosaisilta”) ja muuntaa ne vaatimuksiksi, että tuotteet toimivat rakennettavassa järjestelmässä, ja antaa yksityiskohtaiset vaatimukset siitä, mitä järjestelmässä tarvitaan.

Kurssin analyysi ja suunnittelu (”suunnittelu”)

Analyysin ja suunnittelun tehtävänä on osoittaa, miten järjestelmä tullaan toteuttamaan. Tavoitteena on rakentaa järjestelmä, joka:

suorittaa tietyssä suoritusympäristössä käyttötapausten kuvauksissa määritellyt tehtävät ja toiminnot

täyttää kaikki tarpeet

on helppo ylläpitää, kun toiminnallisissa vaatimuksissa ei tapahdu muutoksia, projektin tulokset analyysi- ja suunnittelumallissa on valinnaisesti analyysimalli.

Suunnittelumallia hyödynnetään käsitteellisenä versiona lähdekoodista, joka näyttää vain vähäisimmän. Näin minkä tahansa tarkastuksen käyttäjä voi todeta, millä tyylillä lähdekoodi on renderöity.

Suunnittelumalli renderöidään siten, että se sisältää erilaisia mallijakoja. Nämä jaottelut on tallennettu tiettyihin osajärjestelmiin.

Kullakin osajärjestelmällä on erillinen käyttöliittymä, joka on tarkasti suunniteltu. Se sisältää myös kuvaukset siitä, miten näihin luokkiin kuuluvat objektit tekevät yhteistyötä käyttötapausten suunnittelun toteuttamiseksi.

Diskurssin toteutus

Sovelluksen vaikutukset ovat:

• Organisaatiokoodi konfiguroidaan sovellusta varten järjestettyihin kerroksellisiin osajärjestelmiin viitaten.
• Komponenttien eri luokat tai jaottelut toteutetaan. Näihin komponentteihin kuuluvat

1. Lähdetiedostot
2. Suoritettavat tiedostot
3. ja
4. Binäärit

• Yksikköinä kehitetyt komponentit testataan

Sisällytetään yksittäisten toteuttajien (tai ryhmien) tuottamat tulokset suoritettavaan järjestelmään. Järjestelmät saavutetaan sovelluksen komponenttien avulla.

Prosessin tavoitteena on suorittaa tärkeä tehtävä, joka on määritellä täsmällinen käytettävä menettely, jotta voidaan käyttää uudelleen komponentteja, jotka ovat joko; jo olemassa tai jotka on juuri otettu käyttöön.

Tämä mahdollistaa järjestelmän ylläpitomahdollisuuden ja parantaa huomattavasti komponenttien käyttömahdollisuuksia.

Discipline Test

Discipline Testin tarkoituksia ovat:

• Tarkistaa objektien välinen vuorovaikutus
• Tarkistaa kaikkien ohjelmistokomponenttien oikea integrointi
• Tarkistaa, että kaikki vaatimukset on toteutettu oikein
• Tunnistaa ja varmistaa, että virheet korjataan ennen ohjelmiston käyttöönottoa
• Varmista, että kaikki virheet on korjattu, tarkistetaan ja suljetaan

Johtopäätökset

Jos projektissa on virheitä, niiden korjaaminen voi viedä tarpeettomia kustannuksia, koska virheitä ei tuoda esiin ajoissa.

Jos projekti kuitenkin testataan kokonaisuudessaan, siitä on hyötyä, koska projektiin mahdollisesti hiipivät virheet voidaan tunnistaa ja todeta mahdollisimman aikaisessa vaiheessa.

Tällöin puolestaan virheiden korjaamisesta aiheutuvat kustannukset pienenevät valtavasti. Tämä on Rational Unified Process -prosessin ehdottama iteratiivinen lähestymistapa.

Testauksen hedelmällisyyden ja parhaan mahdollisen lopputuloksen varmistamiseksi testit on suoritettava neljällä laatuparametrillä, ja lisäksi on määriteltävä standardit, jotka on täytettävä, jotta projektin voidaan katsoa läpäisseen testin.