Aufgabe: System integrieren
Diese Aufgabe beschreibt, wie die Implementierungssubsysteme nacheinander in eine Build integriert werden.
Disziplinen: Implementierung
Beziehungen
RollenPrimärer Ausführender: Zusätzliche Ausführende:
EingabenVerbindlich: Optional:
  • Ohne
Ausgaben
Prozessverwendung
Schritte
Subsysteme akzeptieren und vorläufige Builds erzeugen

Wenn Sie mit dieser Aufgabe beginnen, wurden Implementierungssubsysteme bereitgestellt, um die Anforderungen des nächsten (Ziel) Build zu erfüllen, der im Build-Plan für Integration beschrieben ist. Es muss jedoch beachtet werden, dass der Build-Plan für Integration mehrere Builds in einer Iteration vorschreiben kann. Je nach Komplexität und Anzahl der zu integrierenden Subsysteme ist es häufig effizienter, den Ziel-Build in einer Reihe von Schritten zu erstellen, wobei in jedem Schritt weitere Subsysteme hinzugefügt und mehrere vorläufige Mini-Builds erstellt werden. In diesem Fall kann jeder für eine Iteration geplante Build wiederum eigene vorübergehende Builds haben. Diese Builds müssen einem minimalen Integrationstest (in der Regel einem Teil der Tests, die im Integrations-Build-Plan für diesen Ziel-Build beschrieben sind) unterzogen werden, um sicherzustellen, dass die hinzugefügten Teile mit den bereits im Arbeitsbereich für Systemintegration Teilen kompatibel sind. Probleme lassen sich mit diesem Ansatz leichter isolieren und diagnostizieren.  

Der Integrator akzeptiert die bereitgestellten Subsysteme nacheinander im Arbeitsbereich für Systemintegration und löst dabei alle auftretenden Zusammenführungskonflikte. Im Hinblick auf die Schichtenstruktur wird empfohlen, dabei von unten nach oben vorzugehen, um sicherzustellen, dass die Versionen der Subsysteme unter Berücksichtigung der Importe konsistent sind. Die neu hinzugefügten Subsysteme werden kompiliert und in einem vorläufigen Build verlinkt, der dann dem Tester für einen minimalen Systemintegrationstest bereitgestellt wird.

Im Begleittext beschriebene Abbildung

Diese Abbildung zeigt einen Build, der in drei Schritten erstellt wird. Einige Subsysteme werden nur als Stubs für das Kompilieren und Verlinken der anderen Subsysteme und die Bereitstellung des erforderlichen minimalen Laufzeitverhaltens benötigt.

Der letzte Schritt in der Serie erzeugt den Ziel-Build laut Build-Plan für die Integration. Nachdem dieser Build einem Minimaltest unterzogen wurde, wird eine provisorische Referenzversion für diesen Build erstellt. Hierfür ist die Aufgabe Referenzversionen in der Disziplin Konfigurationsmanagement zuständig. Der Build wird jetzt dem Tester für vollständige Systemtests zur Verfügung gestellt. Art und Detailgrad dieser Tests sind im Build-Plan für Integration festgelegt, wobei für den letzten Build einer Iteration alle Tests ausgeführt werden, die im Iterationstestplan definiert sind.

Referenzversionen hochstufen
Wenn ein Build verschiedene Teststufen passiert, werden die zugehörigen Referenzversionen entsprechend hochgestuft. Hier kommt die Aufgabe Referenzversionen hochstufen in der Disziplin Konfigurationsmanagement in Spiel. Promotion ist ein Mittel, mit dem verdeutlicht werden kann, ob eine Referenzversion eine bestimmte Teststufe passiert oder verfehlt hat. Die Namen der Promotionsstufen werden vom Konfigurationsmanager im Rahmen der Definition der Richtlinien für die Projektkonfiguration definiert. Die Promotionsstufen sind wichtig für die Konsumenten der Referenzversion. Ein Implementierer muss beispielsweise wissen, ob eine Referenzversion stabil und getestet ist, bevor er einen privaten Entwicklungsarbeitsbereich aktualisiert und auf den Stand der Referenzversion im Arbeitsbereich für Systemintegration bringt.
Weitere Informationen