Rational Unified Process in Software Testing
Rational Unified Process (RUP) methodologie maakt gebruik van de object-georiënteerde aanpak in zijn ontwerp en het gebruik van UML (Unified Modeling Language) notatie is ontworpen en gedocumenteerd om de processen in actie te illustreren. Het maakt gebruik van commercieel bewezen technieken en praktijken.
Het is een proces dat wordt beschouwd als zwaar en bij voorkeur toepasbaar op grote ontwikkelingsteams en grote projecten, maar het feit dat het uitgebreid aanpasbaar is, maakt het mogelijk om het aan te passen aan projecten van elke schaal.
Specifiek
Voor projectbeheer biedt het RUP-model (Rational Unified Process) een gedisciplineerde oplossing, zoals de taken en verantwoordelijkheden die binnen een softwareontwikkelingsorganisatie worden geschetst.
RUP (Rational Unified Process) is op zichzelf een softwareproduct. Het is modulair en geautomatiseerd, en de hele methodologie wordt ondersteund door verschillende ontwikkeling tools geïntegreerd en verkocht door IBM via haar “Rational Suites.”
De methoden van de concurrentie op het gebied van software engineering omvatten “clean rooms” (beschouwd als zwaar) en agile (licht), zoals Extreme Programming (XP-Extreme Programming), Scrum, FDD, en anderen.
Er zijn bepaalde richtlijnen en sjablonen die, voor de medewerkers van een productiecyclus, door RUP worden gedefinieerd: een deel van de klant en een evaluatie van de voortgang van het project door het management. Het helpt ontwikkelaars om gefocust te blijven op het project.
Beheervereisten
Prorecte documentatie is essentieel voor elk grootschalig project; merk op dat RUP beschrijft hoe functionaliteit, systeembeperkingen, ontwerpbeperkingen en zakelijke vereisten te documenteren.
De use cases en de scenario’s zijn voorbeelden van afhankelijke proces artefacten, die als veel effectiever zijn beschouwd bij het vastleggen van functionele eisen.
Het gebruik van een component-gebaseerde architectuur
De component-gebaseerde architectuur creëert een systeem dat gemakkelijk kan worden uitgebreid, het bevorderen van hergebruik en software een intuïtief begrip. Een component verwijst gewoonlijk naar een object in object-georiënteerd programmeren.
RUP biedt een systematische manier om dit soort systemen te bouwen, waarbij de nadruk ligt op de produktie van een uitvoerbare architectuur in de vroege stadia van het project, d.w.z. voordat op grote schaal middelen worden vastgelegd.
De Componenten waarnaar hier wordt verwezen, zijn in het algemeen opgenomen in de infrastructuren die reeds ter plaatse bestaan. Deze infrastructuren omvatten zowel CORBA als Component Object Model (COM).
Het gebruik van visuele softwaremodellen in het RUP-model
Door het abstraheren van de programmering van uw code en deze weer te geven met behulp van grafische bouwstenen, kan RUP een effectieve manier zijn om een overzicht van een oplossing te krijgen.
Het gebruik van visuele modellen kan ook individuen met een minder technisch profiel (zoals klanten) in staat stellen een beter begrip te krijgen van een bepaald probleem, en dus meer betrokken te zijn bij het project als geheel.
De UML modelleertaal is een industriestandaard geworden voor het representeren van projecten, en wordt veel gebruikt door RUP!
Know More: Lees over Exclusieve details van Agile Testing
Check Software Quality
Het niet garanderen van softwarekwaliteit is de meest voorkomende mislukking in alle computersysteemprojecten. Meestal denkt men na over de kwaliteit van de software na de voltooiing van de projecten of de kwaliteit is de verantwoordelijkheid van een ander team ontwikkeling.
Management en controle Change Software
In alle software projecten, het bestaan van verandering is onvermijdelijk. RUP definieert methoden om veranderingen te controleren en te bewaken. Aangezien een kleine wijziging toepassingen op totaal onvoorspelbare wijze kan beïnvloeden, is wijzigingsbeheer essentieel voor het succes van een project.
RUP (Rational Unified Process)definieert ook de gebieden van werk en veiligheid, die een programmeur garandeert dat wijzigingen in een ander systeem uw systeem niet zullen beïnvloeden.
Fasen van de RUP-methodologie
Tot zover zijn deze richtlijnen algemeen, waaraan men zich dient te houden gedurende de gehele looptijd van een projectcyclus. De fasen (zie onderstaande figuur) geven de nadruk aan die op een bepaald moment in het project wordt gelegd. Om de temporele dimensie van een project te vatten, verdeelt RUP het project in vier verschillende fasen:
Initiatie of Ontwerp: nadruk op de reikwijdte van het systeem;
Voorbereiding: nadruk op architectuur;
Bouw: nadruk op ontwikkeling;
Overgang: nadruk op de toepassing.
RUP is ook gebaseerd op de 4 P’s:
- People
- Design
- Product
- Process
De lagen zijn opgebouwd uit iteraties. Iteraties zijn vensters van tijd; iteraties heeft de term gedefinieerd zoals de fasen objectief zijn.
Alle fasen genereren artefacten. Deze worden in de volgende fase gebruikt en documenteren het project en maken een betere follow-up mogelijk.
Ontwerpfase
De ontwerp- of initiatieffase bevat de werkstromen die nodig zijn voor de instemming van de belanghebbende partijen – stakeholders – met de doelstellingen, architectuur en planning van het project. Als deze actoren over goede kennis beschikken, zal het niet nodig zijn te analyseren. Anders is een uitgebreidere analyse vereist.
In dit stadium worden de essentiële eisen van het systeem omgezet in use-cases. Het is niet de bedoeling ze helemaal af te sluiten, maar alleen die welke nodig zijn om het advies vorm te geven.
Deze stap is meestal kort en wordt gebruikt om te bepalen of het haalbaar is om met het project door te gaan en de risico’s en de kosten van het laatste te bepalen. Er kan een prototype worden gemaakt dat de klant moet goedkeuren. Zoals de RUP aanhaalt, is het ideaal om iteraties uit te voeren, die goed moeten worden gedefinieerd in termen van hun hoeveelheid en doelstellingen.
Uitwerkingsfase
De voorbereiding zal zijn voor het ontwerp van het systeem, als aanvulling op de enquête en/of documentatie van use cases, voor de architectuur van het systeem, om het business model voor het project te herzien en om te beginnen met de versie van de gebruikershandleiding. Men moet aanvaarden: De productbeschrijving (toename + integratie) is stabiel; Het projectplan is betrouwbaar? De kosten zijn subsidiabel?
Bouwfase
In de bouwfase begint de fysieke ontwikkeling van de software, produktiecodes, alfatests. Beta-tests zijn uitgevoerd aan het begin van de overgangsfase.
U moet de tests, stabiele en test processen te accepteren, en het systeem code is “baseline”.
Overgangsfase
In deze fase is de levering (“deployment”) van software, die de inzet en de levering plan, het toezicht en de kwaliteit van de software uit te voeren. Producten (releases, versies) gaan worden geleverd, en plaats klanttevredenheid. Deze fase vindt ook de opleiding van de gebruikers.
Disciplines van de RUP (Rational Unified Process) Methodologie
De Business Modeling Discipline
Organisaties zijn in toenemende mate afhankelijk van IT-systemen, dus het is absoluut noodzakelijk dat informatiesystemen ingenieurs weten hoe toepassingen worden geïntegreerd in de ontwikkeling van de organisatie. Bedrijven investeren in IT, die het concurrentievoordeel van toegevoegde waarde door technologie begrijpt.
Het doel van business modeling is om eerst een beter begrip en communicatie tussen business engineering en software engineering tot stand te brengen.
Inzicht in de business betekent dat software engineers de structuur en dynamiek van het doelbedrijf (de klant) moeten begrijpen, de huidige problemen waarmee de organisatie wordt geconfronteerd en mogelijke methoden en strategieën om verbeteringen aan te brengen.
Een ander belangrijk aspect dat niet mag worden ondermijnd, is dat de betrokken partijen, zoals de ontwikkelaars, alsmede de klanten en ook de eindgebruikers, een duidelijk begrip moeten hebben van de organisatie, en een belangrijk kenmerk van dit begrip is dat het gemeenschappelijk moet zijn onder alle betrokken partijen.
Business modeling legt uit hoe de visie kan worden beschreven van een organisatie waarin het systeem zal worden geïmplementeerd en hoe deze visie kan worden gebruikt als basis om de processen, functies en verantwoordelijkheden te beschrijven.
Eisen
In deze cursus wordt uitgelegd hoe verzoeken van belanghebbende partijen (“interested parties”) kunnen worden verkregen en omgezet in een pakket van eisen dat de producten werken binnen het te bouwen systeem en worden de gedetailleerde eisen gegeven voor wat nodig is voor het systeem.
Analyse en Ontwerp van de Discipline (“Design”)
Het doel van de analyse en het ontwerp is om te laten zien hoe het systeem zal worden uitgevoerd. Het doel is een systeem te bouwen dat:
Uitvoeren in een specifieke uitvoeringsomgeving, taken en functies die zijn gespecificeerd in de beschrijvingen van use-cases
Voldoet aan alle behoeften
Het is gemakkelijk te onderhouden wanneer er geen wijzigingen in de functionele eisen zijn, de resultaten van het project in een analyse- en ontwerpmodel heeft optioneel een analysemodel.
Het ontwerpmodel wordt gebruikt als een conceptuele versie van de broncode, die alleen het absolute minimum weergeeft. Hierdoor kan de gebruiker van een willekeurige inspectie nagaan in welke stijl de broncode is weergegeven.
Het ontwerpmodel wordt op zodanige wijze weergegeven dat het verschillende divisies van ontwerpen bevat. Deze divisies zijn opgeslagen binnen bepaalde subsystemen.
Elk subsysteem heeft een afzonderlijke interface die nauwkeurig is ontworpen. Het bevat ook beschrijvingen van hoe de objecten in deze klassen samenwerken om het ontwerp van use cases uit te voeren.
De Discipline Implementatie
De effecten van de toepassing zijn:
- Met verwijzing naar de gelaagde subsystemen georganiseerd voor een toepassing, wordt de organisatie code geconfigureerd.
- De verschillende klassen of divisies van componenten worden uitgevoerd. Deze componenten omvatten
- Source Files
- Executables en
- Binaries
- Componenten die als eenheden zijn ontwikkeld, worden getest
De resultaten die door de individuele uitvoerders (of teams) zijn geproduceerd, worden in een uitvoerbaar systeem opgenomen. De systemen worden gerealiseerd door middel van de componenten van de toepassing.
Het proces beoogt een belangrijke functie te vervullen, namelijk het definiëren van de exacte procedure die moet worden gebruikt, om componenten te hergebruiken die ofwel; reeds bestaan of nieuw zijn geïntroduceerd.
Dit maakt het mogelijk het onderhoud van het systeem te bemoeilijken en de kansen op het gebruik van componenten aanzienlijk te verbeteren.
Disciplinetest
De doeleinden van disciplinetests zijn:
- Controle van de interactie tussen objecten
- Controle van de juiste integratie van alle softwarecomponenten
- Controle of alle eisen correct zijn uitgevoerd
- Ontdekken en zorgen dat gebreken worden aangepakt voordat de software wordt geïmplementeerd
- Zorgen dat alle gebreken zijn gecorrigeerd, herzien en gesloten
Conclusie
In het geval dat er gebreken in het project zijn, kan de correctie ervan onnodige kosten met zich meebrengen doordat de gebreken niet tijdig aan het licht worden gebracht.
Als het project echter in zijn geheel wordt getest, is dat gunstig, omdat eventuele gebreken die in het project sluipen, zo vroeg mogelijk kunnen worden geïdentificeerd en vastgesteld.
Dit zal op zijn beurt de kosten die met het verhelpen van de gebreken zijn gemoeid, enorm doen dalen. Dit is de iteratieve aanpak die door het Rational Unified Process wordt voorgesteld.
Om ervoor te zorgen dat de test vruchten afwerpt en de best mogelijke resultaten oplevert, moeten de tests worden uitgevoerd op vier kwaliteitsparameters en moeten er ook vaste normen zijn waaraan moet worden voldaan, wil het project worden beschouwd als geslaagd voor de test.