Introduction

The architecture is expected to be stable when this phase starts, allowing the remaining requirements to be implemented on top of it. Another advantage of validating the architecture and eliminating as many risks as possible during Elaboration is to provide more predictability in Construction, which allows the project manager to focus on team efficiency and cost reduction.

Functionality is continuously implemented, tested, and integrated, resulting in builds that are more and more complete and stable. A beta or prerelease may be deployed to a sampling of the intended audience at the end of Construction. Delivery of the actual release is the main focus of the next phase.

The activities performed in a typical iteration during Construction phase are described after the following introductions to each activity.

Manage iteration

This activity is performed throughout the project lifecycle. The goal of this activity is to identify risks and issues early enough to mitigate them, to establish the goals for the iteration, and to support the development team in reaching these goals.

Similarly to other phases, the project manager (supported by the team) launches the iteration, allocates work, tracks status, and handles issues and risks. Although the high-priority and architecturally significant risks were mitigated during Elaboration, new risks may appear during Construction, such as not having the right amount of resources to obtain the desired degree of parallel development.

The prioritization of work for a given iteration (existing change requests and possibly a few remaining requirements) takes place. project manager, stakeholders, and the remaining team members agree on what is supposed to be developed during that iteration.

At the end of the iteration, the team performs an iteration assessment. The goal is to conduct a retrospective review of the iteration that is ending. As part of this assessment, the objectives for the Construction phase are expected to be demonstrated by the beta-quality release of the software, thus supporting the possibility of transitioning the software to its end users.

Manage requirements

This activity is repeated throughout the lifecycle. The goal of this activity is to understand and prioritize stakeholder needs and associated requirements for the system, as well as to capture these in a form that will support effective communication and collaboration between the stakeholders and the development team.

During Inception, most requirements are captured. The high-risk requirements are detailed, implemented, and validated (through a working architecture) during Elaboration.

During the Construction phase, requirements management demands less time from the analyst. There still may be low-risk requirements to be detailed or refined, but in a way that can be assigned to developers.

Test cases describe which requirements are being tested in that iteration.

Develop solution

This activity is repeated multiple times, in parallel, for each development task planned for that iteration. The main goal of this activity is an executable system that provides the incremental quality and functionality for the specified requirements, within the specified context.

The architecture  was proposed and a baseline established at the end of Elaboration. Critical requirements were expected to be implemented, tested, and integrated as part of the baseline architecture. As the remaining requirements are implemented during Construction, the Architect identifies commonalities among solutions being developed by the various developers and leverages reuse where possible. Some degree of refactoring of the architecture may be needed to accommodate putting common pieces together.

A pattern similar to the Elaboration phase happens during Construction when it comes to breaking down requirements into development tasks and assigning each requirement within a context to a developer. Requirements at this stage are mostly of medium-to-low level of risk, but usually they represent the largest slice from the total amount of requirements to be implemented in a project. Thus, it is expected that this activity is repeated, or instantiated, multiple times (once per requirement within context), thus allowing parallel development. Continuous integration allows functionality to be added to the code base constantly, which helps the achievement of more and more complete builds of the software.

Validate build

This activity is repeated throughout the project lifecycle. The main goal of this activity is to validate the current increment of the system against the requirements allocated to it.

Similarly to Elaboration, this activity happens in parallel with the develop solution activity. The intent is to validate that a stable beta release is achieved and that users can perform acceptance tests.

Ongoing tasks

Similarly to any other phase, any role on the team can submit change requests. The software being developed is achieving beta quality by this point; therefore, defects of high priority are generally addressed during Construction iterations and Transition iterations. Enhancement requests can be planned for either subsequent Transition iterations or a next release of the product.