Rational Unified Process in Software Testing

Rational Unified Process (RUP) metodologien bruger den objektorienterede tilgang i sit design, og brugen af UML (Unified Modeling Language) notation er designet og dokumenteret til at illustrere processerne i aktion. Den anvender kommercielt gennemprøvede teknikker og praksis.

Det er en proces, der betragtes som tung og fortrinsvis anvendelig til store udviklingshold og store projekter, men det faktum, at den i vid udstrækning kan tilpasses, gør det muligt at tilpasse den til projekter af enhver størrelse.

Specifikt

For projektledelse giver RUP(Rational Unified Process)-modellen en disciplineret løsning som f.eks. de opgaver og ansvarsområder, der er skitseret inden for en softwareudviklingsorganisation.

RUP (Rational Unified Process) er i sig selv et softwareprodukt. Den er modulær og automatiseret, og hele dens metodologi understøttes af flere udviklingsværktøjer, der er integreret og sælges af IBM gennem dets “Rational Suites”.”

De konkurrerende metoder inden for softwareudvikling omfatter “rene rum” (betragtes som tunge) og agile (lette) såsom Extreme Programming (XP-Extreme Programming), Scrum, FDD og andre.

Der er visse retningslinjer og skabeloner, der er defineret, for de ansatte i en produktionscyklus, af RUP: en del af kunden og en evaluering af projektets fremskridt af dets ledelse. Det hjælper udviklerne med at holde fokus på projektet.

Ledelseskrav

Den korrekte dokumentation er afgørende for ethvert stort projekt; bemærk, at RUP beskriver, hvordan man dokumenterer funktionalitet, systembegrænsninger, designrestriktioner og forretningskrav.

Brugssager og scenarier er eksempler på afhængige procesartefakter, som er blevet anset for at være langt mere effektive til at indfange funktionelle krav.

Brug af en komponentbaseret arkitektur

Den komponentbaserede arkitektur skaber et system, der let kan udvides, hvilket fremmer genbrug og software en intuitiv forståelse. En komponent henviser normalt til et objekt i objektorienteret programmering.

RUP giver en systematisk måde at opbygge denne type system på, idet der fokuseres på at fremstille en eksekverbar arkitektur i projektets tidlige faser, dvs. før der afsættes ressourcer i stor skala.

De komponenter, der henvises til her, indgår som regel i de infrastrukturer, der allerede findes på stedet. Disse infrastrukturer omfatter CORBA samt Component Object Model (COM).

Brug af visuelle softwaremodeller i RUP-modellen

Gennem at abstrahere programmeringen af din kode og repræsentere den ved hjælp af grafiske byggeklodser kan RUP være en effektiv måde at få et overblik over en løsning på.

Brugen af visuelle modeller kan også gøre det muligt for personer med en mindre teknisk profil (som kunder) at få en bedre forståelse af et givet problem og dermed blive mere involveret i projektet som helhed.

UML-modelleringssproget er blevet en industristandard for repræsentation af projekter, og det bruges i vid udstrækning af RUP!

Vis mere: Læs om Eksklusive detaljer om agil testning

Tjek softwarekvalitet

Det sikrer ikke softwarekvalitet er den mest almindelige fejl i alle computersystemprojekter. Normalt tænker man på softwarens kvalitet efter afslutningen af projekterne, eller kvaliteten er et ansvar for et andet team udviklingsteam.

Administration og kontrol af softwareændringer

I alle softwareprojekter er det uundgåeligt, at der sker ændringer. RUP definerer metoder til at styre og overvåge ændringer. Da en lille ændring kan påvirke applikationer på helt uforudsigelige måder, er ændringskontrol afgørende for et projekts succes.

RUP (Rational Unified Process)definerer også områderne arbejde og sikkerhed, som garanterer en programmør, at ændringer i et andet system ikke vil påvirke dit system.

Faserne i RUP-metodologien

Så vidt er disse retningslinjer generelle, der skal overholdes for at gå gennem livet af en projektcyklus. Faserne (se nedenstående figur) angiver den vægt, der lægges på projektet på et givet tidspunkt. For at indfange den tidsmæssige dimension af et projekt opdeler RUP projektet i fire forskellige faser:

Initiering eller design: vægt på systemets omfang;

Forberedelse: vægt på arkitekturen;

Byggeri: vægt på udviklingen;

Transition: vægt på anvendelsen.

RUP er også baseret på de 4 P’er:

• People
• Design
• Product
• Process

Lagene er sammensat af iterationer. Iterationer er tidsvinduer; iterationer har defineret begrebet, da faserne er objektive.

Alle faser genererer artefakter. Disse vil blive brugt i den næste fase og dokumenterer projektet og giver mulighed for en bedre opfølgning.

Designfasen

Design- eller igangsættelsesfasen indeholder de arbejdsgange, der er nødvendige for, at de interesserede parter – interessenter – kan blive enige om projektets mål, arkitektur og planlægning. Hvis disse aktører har et godt kendskab, vil det ikke være nødvendigt at analysere. I modsat fald er der behov for en mere udførlig analyse.

I denne fase omdannes de væsentlige krav til systemet til use cases. Målet er ikke at lukke dem overhovedet, men kun dem, der er nødvendige for at forme udtalelsen.

Trinet er normalt kort og bruges til at definere, om det er muligt at fortsætte med projektet og definere risici og omkostninger for det sidste. Der kan laves en prototype, som kunden skal godkende. Som RUP citerer, er det ideelle at udføre iterationer, som skal være veldefinerede med hensyn til deres omfang og mål.

Udarbejdelsesfasen

Forberedelsen vil være til design af systemet, som et supplement til undersøgelsen og/eller dokumentationen af use cases, foran systemets arkitektur, til at gennemgå forretningsmodellen for projektet og til at starte versionen af brugermanualen. Man skal acceptere: Produktbeskrivelsen (forøgelse + integration) er stabil; projektplanen er pålidelig? Omkostningerne er støtteberettigede?

Konstruktionsfasen

I konstruktionsfasen starter den fysiske udvikling af softwaren, produktionskoder, alpha-tests. Betatests blev udført i begyndelsen af overgangsfasen.

Du skal acceptere testene, stabile og testprocesser, og systemkoden er “baseline”.

Overgangsfasen

I denne fase er levering (“deployment”) af software, som udfører implementerings- og leveringsplanen, overvågningen og kvaliteten af softwaren. Produkter (udgivelser, versioner) vil blive leveret, og placere kundetilfredshed. I denne fase finder også uddannelsen af brugerne sted.

Discipliner i RUP-metodologien (Rational Unified Process)

Disciplinen forretningsmodellering

Organisationer er i stigende grad afhængige af it-systemer, så det er bydende nødvendigt, at informationssystemingeniører ved, hvordan applikationer integreres i organisationens udvikling. Virksomheder investerer i IT, som forstår den konkurrencemæssige fordel ved den værdi, som teknologien tilfører.

Målet med forretningsmodellering er først at etablere en bedre forståelse og kommunikation mellem forretningsteknik og software engineering.

Forståelse af forretningen betyder, at softwareingeniører skal forstå strukturen og dynamikken i målvirksomheden (kunden), de aktuelle problemer, som organisationen står over for, og potentielle metoder og strategier til at rette op på det.

Et andet vigtigt aspekt, som ikke må undervurderes, er, at de relevante parter såsom udviklerne såvel som kunderne og også slutbrugerne skal have en klar forståelse af organisationen, og et vigtigt træk ved denne forståelse er, at den skal være fælles for alle de involverede parter.

Businessmodellering forklarer, hvordan man beskriver visionen for en organisation, hvori systemet skal implementeres, og hvordan man bruger denne vision som grundlag for at beskrive processer, funktioner og ansvarsområder.

Kursuskrav

Dette kursus forklarer, hvordan man får anmodninger fra interesserede parter (“interesserede parter”) og omdanner dem til et sæt krav til, at produkterne fungerer i det system, der skal bygges, og giver de detaljerede krav til, hvad der er nødvendigt for systemet.

Analyse og design af disciplinen (“Design”)

Sigtet med analyse og design er at vise, hvordan systemet vil blive udført. Målet er at opbygge et system, der:

Udfører i et specifikt udførelsesmiljø opgaver og funktioner, der er specificeret i beskrivelserne af use cases

Ser opfylder alle behov

Det er let at vedligeholde, når der ikke sker ændringer i de funktionelle krav, resultaterne af projektet i en analyse- og designmodel har eventuelt en analysemodel.

Designmodellen udnyttes som en konceptuel version af kildekoden, der kun viser det absolutte minimum. Dette gør det muligt for brugeren af en hvilken som helst inspektion at konstatere den stil, som kildekoden er blevet gengivet i.

Designmodellen gengives på en sådan måde, at den indeholder forskellige opdelinger af designs. Disse opdelinger er gemt i bestemte delsystemer.

Hvert delsystem har en særskilt grænseflade, der er præcist designet. Det indeholder også beskrivelser af, hvordan objekterne i disse klasser samarbejder om at udføre designet af anvendelsestilfælde.

Disciplinen Implementering

Applikationens virkninger er:

• Med henvisning til de lagdelte delsystemer, der er organiseret til en applikation, er organisationskoden konfigureret.
• De forskellige klasser eller opdelinger af komponenter udføres. Disse komponenter omfatter

1. Kildefiler
2. Eksekverbare filer og
3. Binaries

• Komponenter, der er udviklet som enheder, testes

Inkorporeres de resultater, der er produceret af de enkelte eksekutorer (eller hold), i et eksekverbart system. Systemerne opnås gennem komponenterne i applikationen.

Processen har til formål at udføre en vigtig funktion, som er at definere den nøjagtige procedure, der skal anvendes, for at genbruge komponenter, som enten; allerede findes eller er blevet nyligt indført.

Dette giver mulighed for en besværlig vedligeholdelse af systemet og en væsentlig forbedring af chancerne for udnyttelse af komponenter.

Disciplintest

Formålene med disciplintest er:

• Kontrollere interaktionen mellem objekter
• Kontrollere korrekt integration af alle softwarekomponenter
• Kontrollere, at alle krav er blevet udført korrekt
• Identificere og sikre, at defekter bliver behandlet før softwareimplementeringen
• Sørge for, at alle defekter bliver rettet, gennemgås og lukkes

Slutning

Hvis der er fejl i projektet, kan deres korrektion medføre unødige omkostninger, fordi fejlene ikke kommer frem i lyset inden for den fastsatte tid.

Hvis projektet imidlertid testes i sin helhed, vil dette være en fordel, da eventuelle fejl, der måtte snige sig ind i projekterne, kan identificeres og konstateres tidligst.

Dette vil til gengæld have en massiv reduktion i omkostningerne ved udbedring af fejlene. Dette er den iterative tilgang, der foreslås af Rational Unified Process.

For at testen kan bære frugt og få de bedst mulige resultater, skal testene gennemføres på fire kvalitetsparametre, og der skal også være fastsatte standarder, som skal opfyldes, for at projektet kan anses for at have bestået testen.