Activity: Construction Iteration [1..n]
Activities performed in a typical iteration in Construction phase, the involved roles and main objectives.
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
Relationships
Parent Activities
Description

Introduction

Iterations in Construction have a WBS similar to iterations in the Elaboration phase, with activities happening in parallel. There is a different emphasis on how activities address the phase objectives though.

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, since the delivery of the actual release is the main focus of the next phase.

Below you find the activities performed in a typical iteration during Construction phase.

Manage Iteration

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

Manage Requirements

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

During Construction phase, requirements management demands less time from the Analyst, but there still may be low-risk requirements to be detailed or refined, in a way they can be assigned to Developers to work on.

Refine Architecture

The Architecture was proposed and baselined at the end of Elaboration. Critical requirements were expected to be implemented, tested and integrated as part of the baselined 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.

Develop Solution (for requirement) (within context)

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 instantiated multiple times (once per requirement within context), thus alllowing parallel development to happen. 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

Similarly to Elaboration, this activity happens in parallel with Develop Solution activity. The intent is to validate that a stable “beta” release is achieved and users may be able to perform acceptance test.

Ongoing Tasks

Similarly to any other phase, Any Role on the team can submit change requests. Since at this point in time the software being developed is achieving “beta” quality, defects of high priority are generally addressed during Construction iterations and Transition iterations. Enhancement requests can be either planned for subsequent Transition iterations or for a next release of the product.

Assess and Plan Next Iteration

As part of the assessment, the objectives for 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. The prioritization of work for the next iteration (existing change requests and possibly a few remaining requirements) takes place. Project Manager, Analyst, Stakeholders and the remaining team members agree on what is supposed to be developed in the next iterations (either late Construction phase iterations or Transition iterations) or subsequent releases of the product.

Properties
Event-Driven
Multiple Occurrences
Ongoing
Optional
Planned
Repeatable
More Information