• No results found

RUP och dess struktur

1   Inledning

3.4 RUP och dess struktur

3.3.3 Hantering av mjukvaruuppdatering 

Tillvägagångssättet vid en mjukvaruuppdatering varierar beroende av om systemet är en utveckling från grunden, en in-house lösning eller om det bara är en uppdatering av själva mjukvaran (Avison & Fitzgerald, 2002). Under utvecklingen av mjukvaran ändras kontinuerligt de krav och mål som har satts på systemet. Ändringarna sker i varje iteration under processens gång och skapar på så sätt problem för utvecklarna som jobbar med produkten för tillfället. Enligt Kruchten (2000) underlättar RUP-processen att hålla mjukvaruuppdatering under kontroll och se till att alla involverade i systemutvecklingen är synkroniserade.

3.4 RUP och dess struktur 

RUP är indelat i fyra faser som ett projekt går igenom där varje fas avslutas med en milstolpe. I varje fas sker iterationer och efter varje iteration skapas en grund av projektets status där alla artefakter är granskade och godkända för att nästa iteration ska kunna påbörjas. När projektet fortlöper förändras arbetsbördan på det arbete som sker i de olika faserna. En av de stora fördelarna med RUP enligt Arlow & Neustadt (2005) är den målbaserade inriktningen istället för den leveransbaserade inriktningen.

 

Tabell 3:4 Workflow and Phases (Arlow & Neustadt 2005 s.38) 

Inceptionfasen 

Det övergripande målet med Inceptionfasen att uppnå enighet mellan alla berörda intressenter (Kruchten, 2000). Arlow & Neustadt (2005) menar att i denna fas fastställs möjligheterna och

35 riskerna med att genomföra projektet. Detta kan innebära att teknologi kan behöva testas för att säkerställa företagets krav. Kruchten (2000) anser att fasen innehåller en beskrivning på vad som ska och inte ska vara med i systemet/produkten.

Vidare menare Kruchten (2000) att de väsentligaste aktiviteterna i fasen är att formulera projektets omfattning och de viktigaste kraven för att nå fram till en slutprodukt. Genom en prioritering av Use Cases kan de mest centrala funktionaliteterna identifieras och definieras. Artefakter i denna fas är att visionsdokumenten ska beskriva intressenternas behov och den gemensamma visionen för projektet samt en produktdefinition och systemkrav. Enligt Arlow & Neustadt (2005) stäms första milstolpen av i slutet av Inceptionfasen. Om intressenterna är överens om systemets omfattning, kostnads- och tidsuppskattning, samt att prioriteringar, risker och att utvecklingsprocessen verkar trovärdig kan projektet fortlöpa. I annat fall menar Kruchten (2000) att projektet antingen bör avbrytas eller omarbetas grundligt innan det tillåts fortsätta in i nästa fas.

Elaborationsfasen 

Denna fas avser att arbeta fram en stabil och tillförlitlig arkitektur baserad på de arkitektuella och betydelsefulla Use Casen (Kruchten, 2000). Enligt Arlow & Neustadt (2005) är det primära målet med Elaborationsfasen att skapa en kör- och testbar arkitektur som bygger på den specificerade arkitekturen. Dock menar Arlow & Neustadt (2005) att detta inte ska beaktas som en prototyp utan snarare som en första utgåva av det önskade systemet. Kruchten (2000) anser att de primära målen är att, för kravställarna, demonstrera att projektets arkitektur stödjer visionen inom rimliga kostnader och att projektet följer tidsplanen.

Use Case modellen är i detta skede till 80 procent färdig och samtliga aktörer har blivit identifierade och de flesta Use Case beskrivningar är under utveckling. De krav som är icke funktionella kompletteras också. I slutet av elaborationsfasen stäms andra milstolpen av mot att det finns en stabilitet i både krav och arkitektur, samt att de största riskerna har blivit identifierade och eliminerade. Om projektet ska leva vidare måste iterationsplanerna för nästa fas kontrolleras. Detta för att se till att de är tillräckligt detaljerade och trovärdiga och kravställarna ska vara eniga om att visionen kommer att uppnås under rådande omständigheter (Kruchten, 2000).

36 Konstruktionsfasen 

Kruchten (2000) anser att syftet med konstruktionsfasen är att bygga produkten enligt de kriterier som satts upp i de två tidigare faserna. Under denna fas ska alla återstående funktioner för komponenter och applikationer vara integrerade och testade. Arlow & Neustadt (2005) menar att ett nyckelproblem inom denna fas är att behålla integriteten av systemets arkitektur. Det finns annars risk för att systemet blir instabilt vilket kan leda till att servicekostnaderna ökar. De primära målen är enligt Kruchten (2000) att optimera och planera resurserna för att undvika dubbelarbete sam att hålla leveransplanerna för de releaser som planerats.

För att samtliga milstolpar ska anses vara uppnådda måste fasen resultera i en produkt som kan integreras mot avsedda plattformar samt att användarmanual och beskrivning av den nuvarande releasen utförs (Arlow & Neustadt, 2005)

Under konstruktionsfasen utvecklas en betaversion av systemet/produkten och i slutet av fasen stäms tredje milstolpen av mot att produkten är tillräckligt stabil och mogen för att överföras till användarna samt att intressenterna är redo att implementera systemet (Kruchten, 2000).

Transitionfasen 

Denna fas initieras när testningen av betaversionen är klar och systemet är färdigutvecklat (Arlow & Neustadt, 2005). Syftet med fasen är enligt Kruchten (2000) att leverera produkten till slutanvändarna, vilket vanligtvis resulterar i nyutveckling, nya releaser, problemrättningar eller att uppskjutna funktioner slutförs. Kruchten (2000) menar att buggar, implementation och tester fastställs och beroende på vilken typ av produkt som utvecklas variera fasen från väldigt enkla till mycket komplexa.

I slutet av fasen stäms den fjärde milstolpen av och de viktigaste frågorna som ska besvaras är om användarna är nöjda och om utfallet stämmer överrens med förväntningarna. Vid den här tidpunkten avgörs det även om målen är uppfyllda och om en nyutvecklingscykel ska påbörjas (Kruchten, 2000). Arlow & Neustadt (2005) menar att fasen innehåller moment som att rätta till eventuella brister, förbereda användarna för uppstartandet av det nya systemet och att utarbeta en användarmanual. När alla tester är gjorda, alla mål är uppfyllda och allt har blivit

Related documents