Rational Unified Process (RUP) är en systemutvecklingsprocess för design och implementering av IT-system.

RUP grundar sig på utvecklade och testade s.k. "bästa tillämpningar" i en iterativ utvecklingscykel. Tanken är att RUP ska skräddarsys så att det passar den enskilda organisationen och projektet. Utvecklingsmodellen ägs numera av IBM och utvecklas av IBM Rational Software.

RUP baseras på sex stycken tillämpningar som, enligt IBM Rational Software och många systemutvecklare, är testade och är "bästa tillämpningar" i modern systemutveckling. Användning av tillämpningarna minskar risker i mjukvaruprojekt.

Iterativ utveckling till skillnad från vattenfallsmodellen är bevisad lösa många problem som uppstår i mjukvaruprojekt. I en iterativ utvecklingsmodell är det möjligt att gå tillbaka och t.ex. ändra på systemets krav och planera om de följande iterationerna.

Funktionella och icke-funktionella systemkrav bör dokumenteras för att lätt kunna fånga upp och kommunicera verksamhetskraven. För detta ändamål används användningsfall och scenarion i RUP. De är även det fundamentala i designen, implementationen och testningen av systemet.

Komponentbaserad arkitektur ger flexibilitet och effektivare programåtervinning. Komponenter är delsystem som uppfyller en specifikt definierad funktionalitet av hela systemet.

Visuella modeller hjälper till att kommunicera olika aspekter av mjukvaran, samt att de fångar arkitekturens och dess komponenters struktur och beteende. Unified Modelling Language (UML) lämpar sig bäst för visuell modellering enligt IBM Rational Software.

Ett systems kvalitet definieras genom att titta på systemets tillförlitlighet, funktionalitet och prestanda. Kvalitetskontroller är inbyggda i alla aktiviteter i RUP.

Eftersom förändring är ofrånkomligt i systemutveckling är förmågan att kunna hantera förändringar avgörande. RUP hjälper till att kontrollera, återfölja och dokumentera förändringar för att få en lyckad iterativ process.

RUP-projekt delas in i fyra faser som ett projekt går igenom efter hand. Varje fas avslutas med en väldefinierad milstolpe där specifika delmål måste ha uppfyllts. De fyra faserna är (engelsk benämning inom parentes):

• Förberedelse (Inception)
• Etablering (Elaboration)
• Konstruktion (Construction)
• Överlämning (Transition)

Varje fas består av en eller flera iterationer. Antal iterationer och deras längd beror på själva projektet; ett stort projekt behöver ofta fler och längre iterationer. Under varje iteration utförs aktiviteter för att skapa en eller flera artefakter (dokument, program, eller liknande).

Under förberedelsefasen fastställs den grundläggande idén om systemet genom att samla så mycket systemkrav som möjligt. En kandidatsystemarkitektur identifieras och designas samt även systemets nyckelfunktioner. Total kostnad och risk med utveckling av systemet identifieras och beslut om vidareutveckling ska fortlöpande göras. Förberedelsefasens mål är:

• Förstå vad som ska byggas
• Identifiera nyckelfunktioner i systemet
• Designa en prototyp av systemets arkitektur
• Identifiera och förstå projektets kostnad, plan och risk
• Förbereda den stöttande omgivningen på projektet

Normalt har ett projekt ca fem medlemmar under förberedelsefasen. De är oftast projektledaren, en eller två kravanalytiker, en arkitekt, en systemutvecklare och en kravställare (som finns på plats). Om projektet inte avslutar förberedelsefasen på ett fullgott sätt bör projektet avbrytas eller åtminstone tänkas igenom igen.

Under etableringsfasen analyseras problemdomänen; en grundläggande arkitektur fastställs; en första projektplan framställs och de största riskerna med projektet elimineras. Hela systemet måste vara förstått och greppbart för att kunna göra beslut angående systemets arkitektur. Målen med etableringsfasen är:

• Designa användningsfallsmodell
• Konstruera en arkitekturprototyp
• Granska och revidera risklista
• Ta fram projektplan

IBM Rational Software menar att etableringsfasen är den viktigaste av de fyra faserna. Vid fasens avslutande är analys och design av systemet färdigställt. Val görs om det är möjligt och rimligt att gå vidare med konstruktions- och överlämningsfaserna. Precis som i förberedelsefasen bör projektet avbrytas eller tänkas igenom igen om inte fasen avslutas på ett fullgott sätt.

Under konstruktionsfasen utvecklas och testas systemets funktioner. Målet med fasen är att utveckla produkter som har värde för kunden och systemets slutanvändare. Tillsammans med mjukvaran skrivs även manualer och annan dokumentation under fasens gång.

När konstruktionsfasen är slut tas beslut huruvida systemet kan släppas till slutanvändarna för att kunna användas på ett funktionsdugligt sätt i verksamheten. Kravet är ofta att en betaversion av systemet inte bör utsätta projektet för några större risker.

Meningen med överlämningsfasen är att leverera systemet till slutanvändaren. Problem med det levererade systemet tas även omhand i denna fas.

• Rational Software Corporation (2000): Rational Unified Process: Best Practices for Software Development Teams [1]

• Urban Fägnell (2003): RUP - En introduktion [2]

• IBM Rational Unified Process
• IBM Rational Method Composer