Unified Process

Rational Unified Process (forkortet RUP) er en objektorienteret softwareudviklingsproces og et kommercielt produkt fra et firma der siden 2002 har været en del af IBM. IBM står for videreudviklingen af RUP og tilhørende software. Den nuværende version er 9. RUP bruger UML som notationsprog.

Når man kun taler om metoden og ikke det tilhørende software bruger man ofte betegnelsen Unified Process (forkortet UP).

Indholdsfortegnelse

[redigér] Historie

RUP blev oprindeligt udviklet af Ivar Jacobson, Grady Booch og James Rumbaugh mens de arbejdede sammen i firmaet Rational Software. De tre forenede kræfterne for at beskrive en ensartet objektorienteret softwareudviklingsmetode, efter at de hver for sig (samt flere andre) havde arbejdet med flere metoder og teknikker inden for området. Deres fælles arbejde resulterede også i beskrivelsessproget UML.

[redigér] Overblik

UP er en iterativ metode. Overordnet består processen af fire faser: forberedelse, etablering, konstruktion og overdragelse. I enkelte faser deler man op i en række iterationer. Hvor mange iterationer man skal lave i de enkelte faser for at udvikle et konkret stykke software afhængiger af hvor komplekst det er men hver iteration skal ikke tage for lang tid en god ide er at lade hver iteration have en deadline på nogle uger. Inden man starter en iteration, definerer man hvilke ting, der skal med, og når man er færdig med en iteration, har man lavet et program, som slutbrugeren kan prøve og bruge til at vurdere, hvad der skal med i næste iteration.

[redigér] Faser

UP er overordnet opdelt i fire faser:

Forberedelse (Inception): En kort fase, der har til formål at få et overblik over kravene til systemet
Etablering (Elaboration): En lidt længere fase, hvor man dels udvikler centrale dele af systemet, dels får en dybere forståelse af systemets krav og arkitektur
Konstruktion (Construction): Den længste fase, hvor man udvikler de resterende dele af systemet
Overdragelse (Transition): En afslutningsfase, der drejer sig om færdiggørelse og overgang til drift

[redigér] Forberedelse

Forberedelse er ikke kravspecifikation som det kendes fra vandfaldsmodellen, men i stedet en kort fase. hvor man analyserer kritiske krav og fastslår de grundlæggende ideer om systemet. Man skal altså ikke forsøge at lave en udførlig liste med så mange systemkrav som muligt. En kandidatsystemarkitektur identificeres, og der udarbejdes design af systemets nøglefunktioner. Der foretages en risikoanalyse ved udvikling af systemet, og der tages en beslutning, om man skal gennemføre projektet eller ej. Forberedelsesfasens mål er:

Forstå hvad der skal bygges
Identificere nøglefunktioner i systemet og beskrive dem som use cases
Designe en prototype af systemets arkitektur
Identificere og forstå projektets omkostninger, plan og risici
Vælge udviklingsproces og udviklingsværktøjer hertil.

Normalt har et projekt ca. fem medlemmer under forberedelsesfasen. Det er oftest projektlederen, en eller to kravanalytikere, en arkitekt, en systemudvikler og en kravstiller. Hvis gruppen ikke kan gennemføre forberedelsesfasen på en rimelig måde, bør projektet afbrydes eller i det mindste tænkes igennem igen.

[redigér] Etablering

Under etableringsfasen analyseres problemdomænet; en grundlæggende arkitektur fastsættes; den første projektplan laves og de største risici i projektet elimineres. Hele systemet skal være forstået og begribeligt for at man kan beslutte systemets arkitektur. Formålet med etableringsfasen er:

Design Use case
Konstruere en arkitekturprototype
Granske og revidere risikoliste
Udarbejde projektplan

IBM Rational Software mener at etableringsfasen er den vigtigste af de fire faser. Ved fasens afslutning er analyse og design af systemet færdigt. Man afgør om det er muligt og rimeligt at gå videre med konstruktions- og overdragelsesfaserne. Præcis som i forberedelsesfasen bør projektet afbrydes eller tænkes igennem igen hvis ikke fasen afsluttes på en fuldført måde.

[redigér] Konstruktion

Under konstruktionsfasen udvikles og testes systems funktioner. Formålet med fasen er at udvikle produkter der har værdi for kunden og systemets slutbrugere. Udover software skrives også manualer og dokumentation i løbet af fasen.

Når konstruktionsfasen er slut skal det vurderes hvorvidt systemet fungerer godt nok til at kunne bruges af slutbrugeren i virksomheden.

[redigér] Overdragelse

Meningen med overdragelsesfasen er at leverere systemet til slutbrugeren. Problemer med det levererede system tages der hånd om i denne fase.

[redigér] Principper

Metoden har følgende overordnede principper:

Iterativ: Udviklingen foregår i relativt korte iterationer, i hvilke der i varierende grad (afhængig af, hvor langt man er i forløbet) indgår elementer af kravspecifikation, analyse, design, programmering og test mm.
Inkrementel: Hver iteration giver (i princippet) en udvidelse af det færdige system.
Use case drevet: Use cases er kernen i udviklingen og bruges under såvel analyse, design, programmering som test. Hver iteration vil normalt handle om at foretage en fuldstændig udvikling af en eller flere use cases.
Arkitektur-centreret: En solid arkitektur opstilles tidligt i forløbet og er central for at opnå et godt slutresultat.
Risikodrevet: Risici identificeres tidligt i forløbet, og valget af, hvilke use cases man skal koncentrere sig om i starten, foretages ud fra, hvor højt de scorer i risikovurdering (eliminering af de største risici først)