Unified Process

Der er for få eller ingen kildehenvisninger i denne artikel, hvilket er et problem. Du kan hjælpe ved at angive troværdige kilder til de påstande, som fremføres i artiklen.

Unified Process (forkortet UP) er en objektorienteret softwareudviklingsproces eller systemudviklingsmetode udviklet i slutningen af 1990'erne. Unified Process er den uafhængige udgave af den metode, der også kendes som Rational Unified Process (RUP).

Metodens ophavsmænd, Ivar Jacobson, Grady Booch og James Rumbaugh, der havde beskrevet metoden i bogen The Unified Software Development Process i 1999, markedsførte tidligt RUP fra deres firma Rational Software, der siden 2002 har været en del af IBM. Nu er det IBM, der står for videreudviklingen af RUP og det tilhørende software. Den nuværende version er 9. RUP bruger UML som notationsprog.

Historie

Unified Process blev oprindeligt udviklet af Jacobson, Booch og 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, der blev offentliggjort et par år før UP, og normalt vil anvendelse af UP indebære, at man anvender UML til udarbejdelse af en række diagrammer på vejen mod udviklingen af systemet.

Overblik

UP er en iterativ metode. Overordnet består processen af fire faser: forberedelse, etablering, konstruktion og overdragelse. De 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ænger 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 opgaver, der skal løses i iterationen. Disse opgaver afhænger af fasen, men i princippet kan hver iteration indeholde opgaver inden for discipliner som kravafdækning, analyse af problemstillingen, design af løsningen, programmering og test. Der er dog forskel på vægtningen af disciplinerne, jf. beskrivelsen af faserne herunder. Overordnet har man ikke software, der kommer i drift hos brugerne, før sidste fase er afsluttet.

Overblik over Unified Process

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

Forberedelse

Forberedelsesfasen skal ikke ende ud med en kravspecifikation som det kendes fra vandfaldsmodellen, men er i stedet en kort fase, hvor man analyserer kritiske krav og fastslår de grundlæggende visioner for 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.

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:

• Designe use cases
• 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.

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.

Overdragelse

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

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)

Litteratur

• Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. Addison Wesley Longman, 1999. ISBN 0-201-57169-2
• Craig Larman: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2001. ISBN 0-13-092569-1
• Kendall Scott: The Unified Process Explained, 2002. ISBN 0-201-74204-7

Spire Denne artikel om datalogi eller et datalogi-relateret emne er en spire som bør udbygges. Du er velkommen til at hjælpe Wikipedia ved at udvide den.