Rational Unified Process in Software Testing
Die Rational Unified Process (RUP) Methodology verwendet den objektorientierten Ansatz in ihrem Design und die Verwendung der UML (Unified Modeling Language) Notation wurde entwickelt und dokumentiert, um die Prozesse in Aktion zu illustrieren. Es handelt sich um einen Prozess, der als schwerfällig gilt und vorzugsweise auf große Entwicklungsteams und große Projekte anwendbar ist, aber aufgrund der Tatsache, dass er in hohem Maße anpassbar ist, kann er an Projekte jeder Größenordnung angepasst werden.
Besonderheiten
Für das Projektmanagement bietet das RUP (Rational Unified Process)-Modell eine disziplinierte Lösung, wie die Aufgaben und Verantwortlichkeiten innerhalb einer Softwareentwicklungsorganisation.
RUP (Rational Unified Process) ist an sich ein Softwareprodukt. Er ist modular und automatisiert, und seine gesamte Methodik wird von mehreren Entwicklungswerkzeugen unterstützt, die von IBM über die „Rational Suites“ integriert und verkauft werden.
Zu den konkurrierenden Methoden im Bereich des Software-Engineerings gehören „clean rooms“ (als schwer) und agile (leicht) wie Extreme Programming (XP-Extreme Programming), Scrum, FDD und andere.
Es gibt bestimmte Richtlinien und Vorlagen, die für die Mitarbeiter eines Produktionszyklus durch RUP definiert sind: ein Teil des Kunden und eine Bewertung des Projektfortschritts durch das Management. Es hilft den Entwicklern, sich auf das Projekt zu konzentrieren.
Anforderungen des Managements
Eine ordnungsgemäße Dokumentation ist für jedes Großprojekt unerlässlich; beachten Sie, dass RNP beschreibt, wie man Funktionalität, Systemgrenzen, Designbeschränkungen und Geschäftsanforderungen dokumentiert.
Die Anwendungsfälle und die Szenarien sind Beispiele für abhängige Prozessartefakte, die als wesentlich effektiver bei der Erfassung funktionaler Anforderungen angesehen werden.
Die Verwendung einer komponentenbasierten Architektur
Die komponentenbasierte Architektur schafft ein System, das leicht erweiterbar ist, die Wiederverwendung fördert und ein intuitives Verständnis der Software ermöglicht. Eine Komponente bezieht sich in der Regel auf ein Objekt in der objektorientierten Programmierung.
RUP bietet einen systematischen Weg, um diese Art von System aufzubauen, wobei der Schwerpunkt auf der Erstellung einer ausführbaren Architektur in den frühen Phasen des Projekts liegt, d.h. bevor Ressourcen in großem Umfang eingesetzt werden.
Die Komponenten, auf die hier Bezug genommen wird, sind im Allgemeinen in den bereits vorhandenen Infrastrukturen enthalten. Zu diesen Infrastrukturen gehören CORBA sowie das Component Object Model (COM).
Die Verwendung von visuellen Softwaremodellen im Rup-Modell
Durch die Abstrahierung der Programmierung Ihres Codes und die Darstellung mit Hilfe von grafischen Bausteinen kann RUP ein effektiver Weg sein, um einen Überblick über eine Lösung zu erhalten.
Die Verwendung visueller Modelle kann es auch Personen mit einem weniger technischen Profil (wie Kunden) ermöglichen, ein besseres Verständnis für ein bestimmtes Problem zu erlangen und somit stärker in das Projekt als Ganzes einbezogen zu werden.
Die Modellierungssprache UML hat sich zu einem Industriestandard für die Darstellung von Projekten entwickelt und wird von RNP in großem Umfang verwendet!
Wissen Sie mehr: Lesen Sie über exklusive Details des agilen Testens
Softwarequalität prüfen
Es ist nicht gewährleistet, dass die Softwarequalität der häufigste Fehler in allen Computersystemprojekten ist. Gewöhnlich denkt man über die Qualität der Software erst nach Abschluss der Projekte nach oder die Qualität liegt in der Verantwortung eines anderen Entwicklungsteams.
Management und Kontrolle von Software-Änderungen
In allen Software-Projekten ist die Existenz von Änderungen unvermeidlich. Die RNP definiert Methoden zur Steuerung und Überwachung von Änderungen. Da sich eine kleine Änderung auf völlig unvorhersehbare Weise auf Anwendungen auswirken kann, ist die Änderungskontrolle für den Erfolg eines Projekts von entscheidender Bedeutung.
RUP (Rational Unified Process)definiert auch die Bereiche Arbeit und Sicherheit, die einem Programmierer garantieren, dass Änderungen in einem anderen System sich nicht auf das eigene System auswirken.
Phasen der RNP-Methodik
So weit sind diese Richtlinien allgemein gehalten, um durch das Leben eines Projektzyklus zu gehen. Die Phasen (siehe Abbildung unten) geben an, welche Schwerpunkte im Projekt zu einem bestimmten Zeitpunkt gesetzt werden. Um die zeitliche Dimension eines Projekts zu erfassen, unterteilt RUP das Projekt in vier verschiedene Phasen:
Initiation oder Design: Schwerpunkt auf dem Umfang des Systems;
Vorbereitung: Schwerpunkt auf der Architektur;
Konstruktion: Schwerpunkt auf der Entwicklung;
Übergang: Schwerpunkt auf der Anwendung.
RUP basiert auch auf den 4 Ps:
- Personen
- Design
- Produkt
- Prozess
Die Schichten sind aus Iterationen aufgebaut. Iterationen sind Zeitfenster; Iterationen haben den Begriff definiert, da die Phasen objektiv sind.
Alle Phasen erzeugen Artefakte. Diese werden in der nächsten Phase verwendet und dokumentieren das Projekt und ermöglichen eine bessere Nachverfolgung.
Entwurfsphase
Die Entwurfs- oder Initiierungsphase enthält die Arbeitsabläufe, die für die Zustimmung der interessierten Parteien – Stakeholder – zu den Zielen, der Architektur und der Planung des Projekts notwendig sind. Wenn diese Akteure über gute Kenntnisse verfügen, ist eine Analyse nicht notwendig. Andernfalls ist eine ausführlichere Analyse erforderlich.
In dieser Phase werden die wesentlichen Anforderungen an das System in Anwendungsfälle umgewandelt. Ziel ist es, diese nicht abzuschließen, sondern nur diejenigen, die für die Meinungsbildung notwendig sind.
Dieser Schritt ist in der Regel kurz und dient dazu, festzustellen, ob es machbar ist, mit dem Projekt fortzufahren und die Risiken und Kosten des letzten Projekts zu definieren. Es kann ein Prototyp erstellt werden, der vom Kunden genehmigt werden muss. Wie die RNP besagt, ist es ideal, Iterationen durchzuführen, die hinsichtlich ihres Umfangs und ihrer Ziele gut definiert sein müssen.
Ausarbeitungsphase
Die Vorbereitung dient dem Entwurf des Systems, als Ergänzung zur Erhebung und/oder Dokumentation von Anwendungsfällen, vor der Architektur des Systems, zur Überprüfung des Geschäftsmodells für das Projekt und zum Beginn der Version des Benutzerhandbuchs. Das muss man akzeptieren: Die Produktbeschreibung (Erweiterung + Integration) ist stabil; der Projektplan ist zuverlässig? Die Kosten sind förderfähig?
Konstruktionsphase
In der Konstruktionsphase beginnt die physische Entwicklung der Software, Produktionscodes, Alpha-Tests. Beta-Tests wurden zu Beginn der Übergangsphase durchgeführt.
Sie müssen die Tests, stabile und Test-Prozesse zu akzeptieren, und das System-Code ist „Baseline“.
Übergangsphase
In dieser Phase ist die Lieferung („Deployment“) von Software, die die Bereitstellung und Lieferung Plan, die Überwachung und die Qualität der Software führt. Die Produkte (Releases, Versionen) werden ausgeliefert und stellen die Kundenzufriedenheit sicher. In dieser Phase findet auch die Schulung der Benutzer statt.
Disziplinen der RNP-Methodik (Rational Unified Process)
Die Disziplin der Geschäftsmodellierung
Organisationen sind in zunehmendem Maße von IT-Systemen abhängig, so dass es unerlässlich ist, dass Informationssystem-Ingenieure wissen, wie Anwendungen in die Entwicklung der Organisation integriert werden. Unternehmen investieren in IT, die den Wettbewerbsvorteil der Wertschöpfung durch Technologie versteht.
Das Ziel der Geschäftsmodellierung ist es, zunächst ein besseres Verständnis und eine bessere Kommunikation zwischen Business Engineering und Software Engineering herzustellen.
Das Geschäft zu verstehen bedeutet, dass Software-Ingenieure die Struktur und Dynamik des Zielunternehmens (des Kunden), die aktuellen Probleme, mit denen die Organisation konfrontiert ist, und potenzielle Methoden und Strategien zur Abhilfe verstehen müssen.
Ein weiterer wichtiger Aspekt, der nicht unterschätzt werden darf, ist, dass die relevanten Parteien wie die Entwickler sowie die Kunden und auch die Endnutzer ein klares Verständnis über die Organisation haben müssen, und ein wichtiges Merkmal dieses Verständnisses ist, dass es allen beteiligten Parteien gemeinsam sein muss.
Die Geschäftsmodellierung erklärt, wie man die Vision einer Organisation beschreibt, in der das System implementiert werden soll, und wie man diese Vision als Grundlage für die Beschreibung der Prozesse, Funktionen und Verantwortlichkeiten verwendet.
Anforderungen
Dieser Kurs erklärt, wie man Anfragen von interessierten Parteien („interested parties“) erhält und diese in eine Reihe von Anforderungen umwandelt, damit die Produkte innerhalb des zu bauenden Systems funktionieren und die detaillierten Anforderungen für das, was für das System notwendig ist, bereitstellen.
Analyse und Design der Disziplin („Design“)
Der Zweck der Analyse und des Designs ist es, zu zeigen, wie das System ausgeführt werden wird. Ziel ist es, ein System zu bauen, das:
in einer bestimmten Ausführungsumgebung Aufgaben und Funktionen ausführt, die in den Beschreibungen der Anwendungsfälle spezifiziert sind
alle Anforderungen erfüllt
Es ist einfach zu warten, wenn es keine Änderungen in den funktionalen Anforderungen gibt, die Ergebnisse des Projekts in einem Analyse- und Designmodell optional ein Analysemodell hat.
Das Designmodell wird als konzeptionelle Version des Quellcodes verwendet, die nur das Nötigste zeigt. Dies ermöglicht es dem Benutzer einer beliebigen Inspektion, den Stil festzustellen, in dem der Quellcode gerendert wurde.
Das Entwurfsmodell wird so gerendert, daß es verschiedene Unterteilungen von Entwürfen enthält. Diese Unterteilungen sind in bestimmten Subsystemen gespeichert.
Jedes Subsystem hat eine bestimmte Schnittstelle, die genau gestaltet ist. Es enthält auch Beschreibungen, wie die Objekte in diesen Klassen zusammenarbeiten, um den Entwurf von Anwendungsfällen auszuführen.
Die Disziplin Implementierung
Die Auswirkungen der Anwendung sind:
- Mit Bezug auf die geschichteten Subsysteme, die für eine Anwendung organisiert sind, wird der Organisationscode konfiguriert.
- Die verschiedenen Klassen oder Abteilungen von Komponenten werden ausgeführt. Zu diesen Komponenten gehören
- Quelldateien
- Ausführbare Dateien und
- Binärdateien
- Komponenten, die als Einheiten entwickelt wurden, werden getestet
Die Ergebnisse, die von den einzelnen Ausführenden (oder Teams) produziert wurden, werden in ein ausführbares System integriert. Die Systeme werden durch die Komponenten der Anwendung erreicht.
Der Prozess zielt darauf ab, eine wichtige Funktion zu erfüllen, nämlich die genaue Vorgehensweise zu definieren, um bereits vorhandene oder neu eingeführte Komponenten wiederzuverwenden.
Dies ermöglicht eine problemlose Systemwartung und eine wesentliche Verbesserung der Chancen für die Nutzung von Komponenten.
Disziplin-Test
Die Ziele des Disziplin-Tests sind:
- Prüfen der Interaktion zwischen Objekten
- Prüfen der korrekten Integration aller Softwarekomponenten
- Prüfen der korrekten Ausführung aller Anforderungen
- Identifizieren und sicherstellen, dass Defekte vor der Softwareimplementierung behoben werden
- Sicherstellen, dass alle Defekte behoben werden, überprüft und geschlossen werden
Schlussfolgerung
Wenn es im Projekt Mängel gibt, kann deren Behebung unnötige Kosten verursachen, weil die Mängel nicht rechtzeitig ans Licht gebracht werden.
Wird das Projekt jedoch in seiner Gesamtheit getestet, so ist dies vorteilhaft, da etwaige Mängel, die sich in das Projekt einschleichen könnten, frühestmöglich erkannt und festgestellt werden können.
Das wiederum führt zu einer massiven Verringerung der mit der Behebung der Mängel verbundenen Kosten. Dies ist der iterative Ansatz, den der Rational Unified Process vorschlägt.
Damit der Test Früchte trägt und die bestmöglichen Ergebnisse erzielt werden, müssen die Tests anhand von vier Qualitätsparametern durchgeführt werden, und es müssen auch bestimmte Standards festgelegt werden, die erfüllt werden müssen, damit das Projekt als erfolgreich getestet gilt.