Unified Process

Fra Wikipedia, den frie encyklopædi
Gå til: navigation, søg

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[redigér | redigér wikikode]

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[redigér | redigér wikikode]

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.

Overblik over Unified Process

Faser[redigér | redigér wikikode]

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[redigér | redigér wikikode]

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[redigér | redigér wikikode]

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[redigér | redigér wikikode]

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[redigér | redigér wikikode]

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

Principper[redigér | redigér wikikode]

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[redigér | redigér wikikode]

  • 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
It Stub
Denne it-artikel er kun påbegyndt. Hvis du ved mere om emnet, kan du hjælpe Wikipedia ved at udvide den.