Rational Unified Process in Software Testing

Rational Unified Process (RUP)-metodiken använder sig av det objektorienterade tillvägagångssättet i sin utformning, och användningen av UML-notationen (Unified Modeling Language) utformas och dokumenteras för att illustrera processerna i praktiken. Den använder kommersiellt beprövad teknik och praxis.

Det är en process som anses vara tung och företrädesvis tillämplig på stora utvecklingsteam och stora projekt, men det faktum att den är i stor utsträckning anpassningsbar gör att den kan anpassas till projekt av alla storlekar.

Specifikt

För projektledning ger RUP(Rational Unified Process)-modellen en disciplinerad lösning, t.ex. de uppgifter och ansvarsområden som beskrivs inom en organisation för programvaruutveckling.

RUP (Rational Unified Process) är i sig själv en programprodukt. Den är modulär och automatiserad, och hela dess metodik stöds av flera utvecklingsverktyg som integreras och säljs av IBM genom dess ”Rational Suites”.

De metoder som konkurrerar inom området programvaruteknik omfattar ”renrum” (som anses vara tunga) och agila (lätta) som Extreme Programming (XP-Extreme Programming), Scrum, FDD och andra.

Det finns vissa riktlinjer och mallar som definieras, för personalen i en produktionscykel, av RUP: en del av kunden och en utvärdering av projektets framsteg av dess ledning. Det hjälper utvecklarna att hålla fokus på projektet.

Hanteringskrav

Den korrekta dokumentationen är viktig för alla storskaliga projekt; observera att RUP beskriver hur man dokumenterar funktionalitet, systembegränsningar, designrestriktioner och affärskrav.

Användningsfallen och scenarierna är exempel på beroende processartefakter, som har ansetts vara mycket effektivare när det gäller att fånga funktionella krav.

Användningen av en komponentbaserad arkitektur

Den komponentbaserade arkitekturen skapar ett system som lätt kan utvidgas, vilket främjar återanvändning och programvara en intuitiv förståelse. En komponent hänvisar vanligtvis till ett objekt inom objektorienterad programmering.

RUP erbjuder ett systematiskt sätt att bygga den här typen av system, med fokus på att ta fram en exekverbar arkitektur i projektets tidiga skeden, det vill säga innan man engagerar resurser i stor skala.

De komponenter som avses här ingår i allmänhet i de infrastrukturer som redan finns på platsen. Dessa infrastrukturer inkluderar CORBA samt Component Object Model (COM).

Användningen av visuella programvarumodeller i RUP-modellen

Då RUP abstraherar programmeringen av din kod och representerar den med hjälp av grafiska byggstenar kan RUP vara ett effektivt sätt att få en överblick över en lösning.

Användningen av visuella modeller kan också göra det möjligt för personer med en mindre teknisk profil (som kunder) att få en bättre förståelse för ett visst problem och därmed bli mer involverade i projektet som helhet.

Modelleringsspråket UML har blivit en industristandard för att representera projekt och används i stor utsträckning av RUP!

Vissa mer: Läs om Exklusiva detaljer om agil testning

Kontrollera programvarukvalitet

Den säkerställer inte programvarukvalitet är det vanligaste felet i alla datorsystemprojekt. Vanligtvis tänker man på programvarans kvalitet efter att projekten har avslutats eller så är kvaliteten ett ansvar för ett annat utvecklingsteam.

Hantering och kontroll av förändrad programvara

I alla programvaruprojekt är förekomsten av förändringar oundviklig. RUP definierar metoder för att kontrollera och övervaka förändringar. Eftersom en liten förändring kan påverka applikationer på helt oförutsägbara sätt, är förändringskontrollen avgörande för att ett projekt ska lyckas.

RUP (Rational Unified Process)definierar också områdena arbete och säkerhet, vilket garanterar en programmerare att förändringar i ett annat system inte kommer att påverka ditt system.

Faserna i RUP-metodiken

Så här långt är dessa riktlinjer generella, som ska följas gå genom hela livscykeln för ett projekt. Faserna (se figuren nedan) visar vilken vikt som läggs vid projektet vid en viss tidpunkt. För att fånga den tidsmässiga dimensionen i ett projekt delar RUP in projektet i fyra olika faser:

Initiering eller design: betoning på systemets omfattning;

Förberedelser: betoning på arkitekturen;

Byggnation: betoning på utvecklingen;

Transition: betoning på tillämpningen.

RUP bygger också på de fyra Ps:

• People
• Design
• Produkt
• Process

Lagren består av iterationer. Iterationer är tidsfönster; iterationer har definierat begreppet eftersom faserna är objektiva.

Alla faser genererar artefakter. Dessa kommer att användas i nästa fas och dokumenterar projektet och möjliggör en bättre uppföljning.

Designfas

Design- eller initieringsfasen innehåller de arbetsflöden som är nödvändiga för att de berörda parterna – intressenterna – ska komma överens om projektets mål, arkitektur och planering. Om dessa aktörer har goda kunskaper är det inte nödvändigt att analysera. I annat fall krävs en mer genomarbetad analys.

I detta skede omvandlas de väsentliga kraven på systemet till användningsfall. Målet är inte att stänga dem överhuvudtaget, utan endast de som är nödvändiga för att forma yttrandet.

Steget är vanligtvis kort och används för att definiera om det är möjligt att fortsätta med projektet och definiera riskerna och kostnaden för det sista. En prototyp kan göras för att kunden ska godkänna den. Som RUP citerar är idealet att utföra iterationer, som måste vara väldefinierade när det gäller mängd och mål.

Utvecklingsfasen

Förberedelserna kommer att vara för utformningen av systemet, som ett komplement till kartläggningen och/eller dokumentationen av användningsfall, inför systemets arkitektur, för att se över affärsmodellen för projektet och för att påbörja versionen av användarmanualen. Man måste acceptera: Produktbeskrivningen (ökning + integrering) är stabil, projektplanen är tillförlitlig? Kostnaderna är godtagbara?

Konstruktionsfas

I konstruktionsfasen börjar den fysiska utvecklingen av programvaran, produktionskoder, alfa-tester. Betatester utfördes i början av övergångsfasen.

Du måste acceptera testerna, stabila och testprocesser, och systemkoden är ”baseline”.

Övergångsfas

I den här fasen är leveransen (”deployment”) av mjukvara, som utför deployment- och leveransplanen, övervakningen och kvaliteten på mjukvaran. Produkter (utgåvor, versioner) kommer att levereras, och plats kundnöjdhet. I detta skede sker också utbildning av användarna.

Discipliner i RUP-metodiken (Rational Unified Process)

Disciplinen affärsmodellering

Organisationer blir alltmer beroende av IT-system, så det är absolut nödvändigt att informationssystemingenjörer vet hur applikationer integreras i utvecklingen av organisationen. Företag investerar i IT, som förstår konkurrensfördelen med det värde som tekniken tillför.

Målet med affärsmodellering är att först etablera en bättre förståelse och kommunikation mellan affärsteknik och programvaruteknik.

Förståelse för verksamheten innebär att programvaruingenjörer måste förstå strukturen och dynamiken i målföretaget (kunden), de aktuella problem som organisationen står inför och potentiella metoder och strategier för att göra rättelse.

En annan viktig aspekt som inte får undergrävas är att de berörda parterna, såsom utvecklarna såväl som kunderna och även slutanvändarna, måste ha en tydlig förståelse för organisationen, och en viktig egenskap hos denna förståelse är att den måste vara gemensam för alla berörda parter.

Businessmodellering förklarar hur man beskriver visionen av en organisation där systemet ska implementeras och hur man använder denna vision som grund för att beskriva processer, funktioner och ansvarsområden.

Krav på kursen

Denna kurs förklarar hur man får förfrågningar från berörda parter (”berörda parter”) och omvandlar dem till en uppsättning krav på att produkterna ska fungera i det system som ska byggas och ger de detaljerade kraven på vad som är nödvändigt för systemet.

Analys och utformning av disciplinen (”utformning”)

Syftet med analysen och utformningen är att visa hur systemet ska utföras. Målet är att bygga ett system som:

Utför i en specifik utförandemiljö uppgifter och funktioner som specificeras i beskrivningarna av användningsfall

tillfredsställer alla dina behov

Det är lätt att underhålla när det inte finns några förändringar i de funktionella kraven, projektets resultat i en analys- och designmodell har valfritt en analysmodell.

Designmodellen används som en konceptuell version av källkoden, som endast visar det absolut minsta. Detta gör det möjligt för användaren av en inspektion att fastställa i vilken stil källkoden har återgivits.

Designmodellen återges på ett sådant sätt att den innehåller olika indelningar av design. Dessa uppdelningar lagras inom bestämda delsystem.

Varje delsystem har ett distinkt gränssnitt som är exakt utformat. Det innehåller också beskrivningar av hur objekten i dessa klasser samarbetar för att genomföra designen av användningsfall.

Disciplinen Implementering

Effekterna av applikationen är:

• Med hänvisning till de skiktade delsystemen som organiseras för en applikation konfigureras organisationskoden.
• Den olika klasserna eller indelningarna av komponenterna genomförs. Dessa komponenter inkluderar

1. Källfiler
2. Exekverbara filer och
3. Binärfiler

• Komponenter som utvecklats som enheter testas

Införliva de resultat som producerats av de enskilda exekutörerna (eller grupperna), i ett körbart system. Systemen uppnås genom applikationens komponenter.

Processen syftar till att utföra en viktig funktion, nämligen att definiera det exakta förfarande som skall användas, för att återanvända komponenter som antingen; redan existerar eller har introducerats nyligen.

Detta ger möjlighet till ett krångligt systemunderhåll och en väsentlig förbättring av chanserna att använda komponenter.

Disciplintestning

Syftet med disciplintestning är:

• Kontrollera interaktionen mellan objekt
• Kontrollera korrekt integration av alla programvarukomponenter
• Kontrollera att alla krav har utförts korrekt
• Identifiera och se till att defekter åtgärdas innan programvaruimplementeringen
• Säkerställa att alla defekter korrigeras, granskas och avslutas

Slutsats

Om det finns brister i projektet kan korrigeringen av dem medföra onödiga kostnader på grund av att bristerna inte kommer fram i tid.

Om projektet däremot testas i sin helhet skulle detta vara fördelaktigt eftersom eventuella defekter som kan smyga sig in i projekten kan identifieras och konstateras tidigast.

Detta kommer i sin tur att ha en massiv minskning av de kostnader som är förknippade med rättandet av defekterna. Detta är det iterativa tillvägagångssätt som föreslås i Rational Unified Process.

För att testet ska bära frukt och ge bästa möjliga resultat måste testerna genomföras på fyra kvalitetsparametrar och det måste också finnas fastställda standarder som måste uppfyllas för att projektet ska anses ha klarat testet.