The purpose of this workflow detail is to integrate changes from multiple implementers to create a new consistent version of an Implementation Subsystem.


Topics

Integrator Integrate Subsystem Implement Developer Test Execute Developer Test Design Model Developer Test Test Log Componenets - from Implementer X Componenets - from Implementer Y Implementation Subsystem Build Implementer


Description To top of page

If several implementers work (as a team) in the same Implementation Subsystem, the changes from the individual implementers need to be integrated to create a new consistent version of the Implementation Subsystem. The integration results in series of builds in a subsystem integration workspace. Each build is then integration tested by a tester and/or an implementer executing the developer tests. Following testing, the Implementation Subsystem is delivered into the system integration workspace.

Related Information To top of page

This section provides links to additional information related to this workflow detail.

Timing To top of page

Starts in Elaboration phase, recurs through Construction and Transition phases.

Optionality To top of page

Recommended for larger systems. Optional for smaller systems.

How to Staff To top of page

Integration is typically carried out by a single person (for a small project on which the build process in simple) or a small team (for a large project on which the build process is complex). The integrators need experience in software build management, configuration management, and experience in the programming language in which the components to be integrated are written. Because integration often involves a high degree of automation, expertise in operating system shell or scripting languages and tools like 'make' (on Unix) is also essential.

Work Guidelines To top of page

Integration work is typically automated to a large degree, with manual effort required when the build breaks. A frequent strategy is to perform automated nightly builds and some automated testing (usually at the unit level), allowing for frequent feedback from the build process.



Rational Unified Process   2003.06.13