RUP - En introduktion
Förord
RUP
Rational Unified Process har på senare tid blivit en av de dominerande utvecklingsprocesserna vid systemutveckling. Men vad innebär då RUP? Den här artikeln ger dig en introduktion till RUP:s spännande och omfattande värld utan att gå alltför djupt i detaljer.Innehåll
»»
»
»
»
»
»
»
»
»
»
»
»
Relaterade artiklar
» RUP - Construction» RUP - Elaboration
» RUP - Inception
» RUP - Transition
Historia
Utvecklingen av det som idag är Rational Unified Process är sprungen ur utveckling och användning av ett flertal metoder och arbetssätt under en lång tid. 1987 släpptes Objectory Process vilken senare utvecklades till Rational Objectory Process 1997 och senare Rational Unified Process 1998. Många källor har influerat av det som idag är RUP, utan att försöka identifiera alla så kan några av intresse nämnas:
1987 lämnade svensken Ivar Jacobsson Ericsson för att i egen regi jobba med Objectory, 1995 anslöt sig Ivar till Rational och kom tillsammans med Grady Booch och James Rumbaugh att leda arbetat med att forma det som senare blev RUP.
Begrepp
Användningsfall Ett användningsfall är en beskrivning av VAD ett system gör inte HUR. Det definierar ett beteende hos ett ett sytem eller del därav. Det beskriver ett antal aktiviteter som ska resultera i ett mätbart slutmål för användaren. Användningsfallet består oftast av ett huvudflöde och ett antal alternativflöden. Välskrivna användningsfall underlättar senare arbete i processen med kravinsamling, kravhantering, test och användardokumentation.
Artefakt
Information som används eller skapas som en del av mjukvaruutvecklingen, det kan var dokument, modell eller programkod. Man skulle generellt kunna säga att allt som bör ligga under versionshantering är en artefakt.UMLUnified Modeling Language, ett språk konstruerat för att modellera, illustrera och dokumentera de olika delar ett mjukvarusystem består av. Rational förespråkar UML som notationsspråk, men det är ju naturligtvis upp till projektet att avgöra vilken modellering som skall implementeras i projektet.
RUP:s grundstenar
Det finns några saker som är signifikant för RUP och de fyra viktigaste sakerna är:
Användningsfallsdrivet
Identifierade användningsfall samlas upp i en användningsfallsmodell. Modellen står som utgångspunkt för systemets funktionalitet och tekniska miljö. Användningsfallen kommer att spela en central roll genom hela utvecklingsprocessen fram till färdigt system.
Arkitekturcentrerat
Arkitekturen spelar en central roll i RUP, man använder ett objektorienterat synsätt och designar systemet visuellt med UML. I och med arkitekturens centrala roll kommer arkitekturella och tekniska risker att identifieras tidigt i processen.
Iterativ och inkrementell
Till skillnad från klassiska utvecklingsmetoder såsom vattenfallsmodellen där det färdiga systemet levereras i princip i sin helhet bygger RUP på många små komponentleveranser. Inom varje iteration som finns specificerad i iterationsplanen beskrivs vilka artefakter som skall ingå. Att arbeta objektorienterat blir mer och mer självklart ju längre in i utvecklingsprocessen man kommer och iterationerna blir fler samt att systemet växer.
Arbetsflöde
Det iterativa flödet i som sker genom hela processen illustreras ovan.
Processen
RUP är indelat i fyra faser där olika arbetsflöden och artefakter produceras.
Inception
Starten av processen. Här skapas och formuleras projektets syfte och mål i ett visionsdokument, riskbedömning, resursplanering, projektplan inkl milstolpar. En stabil arkitektur eller åtminstone arkitekturplan skall etableras, prototypen kan och skjuts ofta till nästa fas i processen om projektledaren gör den bedömningen. Resursmässigt så innehåller projektet fortfarande begränsat med personal. En etablerad ordlista skall ha upprättats så att samtliga i projektet pratar samma språk (Av egen erfarenhet vet jag att begrepp och uttryck kan användas vårdslöst och ej betyda samma sak för beställaren varför det är av yttersta vikt att reda ut såna saker tidigt i projektet). Vad beträffar användningsfall så skall man här ha identifierat 50% procent av användningsfallen och specificerat 10% av dessa (detta kan kännas lite vagt att försöka identifiera 50% när man inte känner till resten, men med en god analys i botten kan det uppnås). Innan inceptionsfasen avslutas skall beslut tas om projektet skall övergå i ett fullskaligt utvecklingsprojekt. Alternativt fortsatt utredning runt identifierade problem och risker.Om beslutet att lägga ner projektet tas av någon anledning har man här gjort en stor besparing jämfört med ett vattenfallsprojekt där man skulle ha lagt ner så stora resurser att ingen förmodligen hade våga ta beslutat att lägga ner utan det hade förmodligen resulterat i en produkt med stora brister - missnöjd mottagare och besvikna projektmedlemmar. Eftersom RUP är så komplext och består av så många komponenter är det här viktigt att processen här skräddarsys för att passa projektet så att RUP blir ett stöd i arbetet och inte en belastning.
ElaborationDenna fas skall identifiera så många krav som möjligt för att kunna skapa en stabil arkitektur, de användningsfall som visat sig vara de som är belagda med störst risker och problem skall lyftas fram för att kunna skapa en körbar prototyp för just dessa problem. Nu skall ungefär 80% av användningsfallen ha identifierats och mellan 40-80% av dessa skall vara specifierade. Som ett resultat av denna fas skall ungeför 10% av koden produceras här och detta med fokus på de användningsfall som är arkitekturellt signifikanta för systemet. I denna fas utökas projektgruppen med fler personer, de personer som tidigare varit med tidigare är nu kunskapsbärare och bör behållas åtminstone ett tag innan tidigare inhämtad kunskap överförts till de nya medlemmarna. Användargränssnittsprotoyper upprättas och iterationsplaneringen bör nu vara etablerad för fortsatt utveckling.
ConstructionHär implementeras framtagna artefakter. Det övergripande målet för constructionfasen är att tillverka en första betarelease som skall testas av användarna i en produktionslik miljö, ej i utvecklingsmiljö. I de tidigare faserna har de stora riskerna eliminerats eller planering har gjorts för hur de ska elimineras.
Alla användningsfall är fortfarande inte identifierade när fasen startar och ännu fler har ej specificerats. Detta innebär att många av aktiviteterna nu handlar om att identifiera och specificera resterande användningsfall och att analysera, designa och implementera samtliga specifikationer.
De modeller och artefakter som skapats tidigare i processen måste hållas uppdaterade i takt med att nya krav samlas in och förändringar görs.
Constructionfasen delas in i ett antal iterationer där uppsatta och tydliga mål finns, när dessa är uppfyllda kan projektet gå vidare till nästa iteration. Kvaliteten granskas fortlöpande, man kommer i detta skede att ha en god känsla för hur testerna kommer att gå vilket i sin tur gör att man kan börja planera för den sista fasen.
TransitionDen sista fasen i processen där systemet skall levereras.
Produkten skall testas i målmiljön, paketeras för leverans och användare skall utbildas.
Tid och resurser
En beskrivning av tid och resursfördelning i ett RUP projekt
6 Best practices enligt RUP
Utveckla iterativt
Hantera krav
Använd komponentarkitektur
Modellera Visuellt (UML)
Verifiera kvaliteten kontinuerligt
Hantera förändringar
Sammanfattning
RUP kan grovt sammanfattas med följande fyra fasers beskrivning:Inception (förberedelse)
- Skapa en gemensam vision
Elaboration (Etablering)
- Skapa en arkitektur
Construction (Bygg)
- Skapa en produkt
Transition (Överlämnande)
- Installera och leverera
Artikeln kommer att följas upp med en mer ingående artikel för varje fas, samt ev fler artiklar i ämnet om intresse finns. Lämna gärna synpunkter eller kom med frågor. Och glöm inte rösta på artikeln.
Mattias Järnhäll
Se rubrik.. Att hämta info från en bok är okej, men att skriva rakt av vet jag inte om jag tycker är ok!? Du skulle åt minståne kunnat kosta på dig att referera till boken.