 |
Dieses Artefakt erzeugt eine betriebsfähige Version eines Systems oder Teils eines Systems, das einen Teil der Funktionalität demonstriert, die im Endprodukt bereitgestellt werden muss. Ein Build umfasst eine oder mehrere Implementierungselemente (häufig ausführbare Dateien), die wiederum aus anderen Elementen durch Kompilierung und Verlinken von Quellcode erstellt werden. |
|
Zweck
Ein Build, der sich aus anderen Elementen in der Implementierung zusammensetzt, ist eine testfähige Teilmenge der
Laufzeitfunktionen und Fähigkeiten des Systems. Rational Unified Process (RUP) empfiehlt, während einer Iteration
mehrere Builds zu erstellen und jeden neuen Build durch Funktionen zu erweitern, wenn Elemente aus
Implementierungssubsystemen hinzugefügt oder verbessert werden. Builds können auf allen Ebenen eines Systems erstellt
werden und sich auf ein oder mehrere Subsysteme erstrecken. In RUP liegt das besondere Augenmerk jedoch auf den Builds,
die im Build-Plan für die Integration definiert sind, da diese Builds die
Trittsteine bei der Durchführung der Iteration sind. Falls Größe oder Komplexität des Systems es erfordern, kann der
Build-Plan für Integration in mehrere Pläne für die einzelnen Subsystem unterteilt werden.
Inoffizielle Builds können von einem Implementierer aus mehreren Gründen erstellt werden, z. B. für Einheitentests mit
Elementen aus dem persönlichen Entwicklungsbereich des Implementierers und bei Bedarf auch aus dem Subsystem und den
Systemintegrationsarbeitsbereichen. In diesem Kontext werden Builds jedoch von einem Integrator aus gekenzeichneten
Versionen von Elementen, die die Implementierer dem Subsystem bzw. den Systemintegrationsarbeitsbereichen bereitstellt,
nach dem Build-Plan für Integration erstellt.
|
Beziehungen
Rollen | Verantwortlich:
| Geändert von:
|
Ausgabe von |
|
Eigenschaften
Optional |  |
Geplant |  |
Anpassung
Darstellungsoptionen | UML-Darstellung: Paket im Implementierungsmodell (entweder das Paket der Ausgangsebene oder ein Implementierungssubsystem)
mit dem Stereotyp <<Build>>.
Builds sind natürlich verbindlich, allerdings ändern sich die Arten der Builds, die ein Projekt produziert, im
Verlauf des Lebenszyklus. In der Konzeptionsphase kann der Schwerpunkt auf der Produktion von Prototypen liegen, um das
Problem besser zu verstehen und besser mit dem Kunden kommunizieren zu können. In der Ausarbeitungsphase kann sich der
Schwerpunkt auf die Produktion einer stabilen Architektur und in der Konstruktionsphase auf das Hinzufügen von
Funktionalität verlagern. In der Übergangsphase liegt das Hauptaugenmerk darauf sicherzustellen, dass die Software eine
Qualität erreicht, die eine Auslieferung rechtfertigt.
|
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|