Rational Unified Process

Fra Wikipedia, den frie encyklopedi
Gå til: navigasjon, søk

Rational Unified Process (RUP) er en iterativ og inkrementell programvareutviklingsprosess, med røtter i spiralmodellen, for å sikre et resultat med høyt kvalitetsnivå. RUP er en spesifikk implementasjon av Unified Process.

Med RUP kan man tilpasse og skreddersy utviklingsprosessen til å passe prosjektets behov. Dette oppnår den ved å være iterativ (gjentagende), ved å fokusere på risiko tidlig i utviklingsfasen og ved å integrere fasene. Utviklerne lærer ved hver iterasjon og skreddersøm av prosessen kan forbedres.

Faser[rediger | rediger kilde]

RUP er delt inn i fire faser som gir føringer for ulike hovedfokus:

Inception (Innledning)[rediger | rediger kilde]

  • Finne grensene for prosjektet, identifisere interessenter og avdekke funksjonelle (fra brukere) og ikke-funksjonelle krav.
  • Diskutere risiko og kostnader.
  • Design og brukskvalitet.
  • Planlegging.
  • Milepel: Lifecycle Objective

Elaboration (Utforming)[rediger | rediger kilde]

  • Planlegge arkitektur og systemkravene.
  • Finne farer og problemstillinger og løse disse før man går videre i utviklingen.
  • Produsere en arkitekturprototype.
  • Design.
  • Demonstrere systemet til interessenter.
  • Milepel: Lifecycle Architecture

Construction (Bygging)[rediger | rediger kilde]

  • Programmering.
  • Utvikling av systemet.
  • Oppnå et produkt så fort som mulig ved at bruker/interessenter får testet systemet og komme med tilbakemeldinger.
  • Milepel: Initial Operational Capability

Transition (Overgang)[rediger | rediger kilde]

  • Teste ut en betaversjon for å avdekke feil og mangler som bør utbedres før det ferdige systemet utgis.
  • Opptrening av brukere og de som skal vedlikeholde systemet
  • Eventuelt konvertere eksisterende databaser så de fungerer opp i mot det nye systemet.
  • Feilretting.
  • Milepel: Product Release

Disipliner[rediger | rediger kilde]

RUP er også delt inn i ni "fag"disipliner:

Business modelling (Forretningsmodellering)[rediger | rediger kilde]

  • Opprette en bedre forståelse og kommunikasjon mellom forretnings utviklere og software utviklere.
  • Forstå strukturen og dynamikken til forretningen/organisasjonen/interessenten som skal bruke systemet.
  • Finne nåværende problemstillinger og mulige forbedringer.

Requirements (Kravspesifisering)[rediger | rediger kilde]

  • Beskrive hva systemet skal gjøre.
  • Lage et Bruksmønster Diagram.

Analysis and Design (Analyse og design)[rediger | rediger kilde]

  • Skal vise hvordan systemet vil bli realisert i gjennomføringsfasen.
  • Resultere i en design og analyse modell.

Implementation (Gjennomføring)[rediger | rediger kilde]

  • Implementere klasser og objekter i systemet.
  • Teste og utvikle komponenter til systemet.
  • Sette sammen de ulike delene til et system.

Test (Testing)[rediger | rediger kilde]

  • Bekrefte interaksjonen mellom objekter.
  • Bekrefte riktig integrasjon av alle komponenter i systemet.
  • Bekrefte at alle behovene i systemet er implementert riktig.
  • Finne og identifisere feil i systemet og korrigere disse før utviklingsfasen.

Deployment (Utplassering)[rediger | rediger kilde]

  • Produsere en produkt utgivelse.
  • Distribuere produktet til interessenter.
  • Drive support for produktet.

Configuration and Change Management (Konfigurering og endringsledelse)[rediger | rediger kilde]

  • Konfigurasjonsledelse.
  • Forandringsforespørsel ledelse.
  • Status og mål ledelse.

Project Management (Prosjektledelse)[rediger | rediger kilde]

  • Risiko behandling.
  • Planlegging av prosjektet.
  • Overvåking av prosessens utvikling.

Environment (Omgivelser)[rediger | rediger kilde]

  • Beskrive aktivitetene som er nødvendig for utviklingsprosessen.
  • Forberede prosjekt-spesifikke midler.
  • Lage en utstyrsliste over nødvendig utstyr for prosjektet.

Egenskaper[rediger | rediger kilde]

En av de unike egenskapene med RUP er at alle disiplinene mer eller mindre strekker seg over alle fasene. For eksempel vil "Testing" disiplinen starte i innledningsfasen og ikke etter bygningfasen som man kanskje skulle tro. Men tilstedeværelsen av "Testing" vil gradvis bli høyere frem til slutten av bygningfasen, for så å avta. Tilstedeværelsen av "testing" vil aldri forsvinne helt. Denne egenskapen gjør Rational Unified Process meget motstandsdyktig mot feil og meget tilpasningsdyktig i forhold til forandring i spesifikasjonene, implementasjonen og/eller behovene.

Programvare[rediger | rediger kilde]

Hovedutviklingsprogramvaren for RUP er Rational Rose, utviklet av Rational Software og eid av IBM. Det finnes flere gratis program som lar deg jobbe med RUP, men disse er dog ikke fullt så kraftige og mangler noe funksjonalitet i forhold til Rational Rose. De viktigste freeware-alternativene til Rational Rose er Poseidon og ArgoUML.

Historikk[rediger | rediger kilde]

RUP ble skapt som produkt i 1996 da Rational Software ervervet Objectory, en use case basert programvareutviklingsprosess utviklet av Ivar Jacobson.

IBM ervervet RUP i februar 2003 i forbindelse med oppkjøpet av Rational Software.

I 2006 donerte IBM et subsett av RUP skreddersydd for smidige prosjekter til Eclipse Foundation som publiserte den som åpen kilde"kode" metoden OpenUP[1].

Referanser[rediger | rediger kilde]

  1. ^ http://epf.eclipse.org/wikis/openup/