Introduction

Most activities during a typical iteration in Elaboration phase happen in parallel. Essentially, the main objectives for Elaboration are related to better understanding the requirements, creating and establishing a baseline for the architecture for the system, and mitigating top-priority risks.

The activities performed in a typical iteration during the Elaboration phase are described below.

Manage iteration

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

The project manager and the team launche the iteration, allocating work items to team members (some project teams will prefer to have members volunteer to perform work). The project manager collaborates with the team to break down the work items into development tasks to perform in that iteration. This provides a more accurate estimate of time to spend on what can be realistically achieved.

As the iteration runs, the project manager performs monitoring and control of the project by regularly checking the status of work completed, the work to do next, and issues blocking the progress. In some projects, this checking occurs in daily meetings, which allows for a more precise understanding of how the work in an iteration is progressing. As needed, the team makes corrections to achieve what was planned. The overall idea is that risks and issues are identified and managed throughout the iteration. and everyone knows the project status.

The prioritization of work for a given iteration takes place. Project manager, stakeholders, and the remaining team members agree on what is supposed to be developed during that iteration.

As in any other iteration assessment, demonstration of implemented functionality planned for that iteration is the key success criterion. During iteration assessments in Elaboration, though, keep the phase objectives in mind. As Elaboration iterations are performed, an executable architecture evolves, and you establish a baseline at the end of the phase. In addition, requirements are better understood and detailed. Essential risks, including the architectural ones, have been mitigated. These results help the project manager produce more accurate estimates for the project schedule and cost.

Manage requirements

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

During the Elaboration phase, requirements can still be captured and outlined as customer needs arise. The prioritization of requirements determines when new requirements are going to be implemented. High-risk, architecturally significant requirements are detailed to the extent necessary to be able to use that information as input to architecture and development activities in the current iteration, plus in planning for the next iteration.

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

Note:

The emphasis on finding, outlining and detailing requirements varies from phase to phase. Iterations in Inception and early Elaboration tend to focus more on identifying and outlining requirements in general and on detailing high-priority and architecturally significant requirements. During iterations in late Elaboration and early Construction, the remaining requirements are usually outlined and detailed.

Define the architecture

This activity is repeated in each iteration in the Elaboration phase. The main goal of this activity is to propose an architecture that addresses the requirements with high architectural risks, thus providing a solid, yet resilient, foundation on which to build the system functionality.

The architect analyzes the architectural constraints, identifies available assets to build the system, defines how the system will be structured, and identifies the initial abstractions and mechanisms that must be provided by the architecture.

Throughout all of the iterations, the architect:

• Identifies commonalities between different requirements to leverage reuse
• Defines strategies for achieving requirements related to quality
• Captures and communicates architectural decisions

Develop solution for requirement within context

This activity is instantiated 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.

As the requirements planned for the iteration are broken down into development tasks, these are assigned by the project managers to developers (some project teams prefer to have team members sign up for development tasks themselves).

The solution to be developed is for a particular requirement within a context, which reflects the idea of breaking down requirements into development tasks. As an example, a particular use-case scenario within the context of database access could be assigned to a developer; whereas, the same scenario within the user interface and business logic contexts could be assigned to a different developer. In this example, more than one developer is working on a particular piece of functionality to be delivered in a particular iteration. As they develop the requirement within the context they were assigned to, they perform tests and integrate their work to create builds.

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.

The intent is to validate that the high-priority requirements implemented reflect a robust architecture so that remaining requirements can be implemented on top of that architecture. As developer develop the solution for the requirements in a given iteration, the integrated source code is unit-tested. Then, a separate tester conducts system-level testing in parallel with development to make sure that the solution, which is continuously being integrated, matches what is specified in the requirements. Then, the tester defines what techniques to use, what the data input is, what test suites to create. As tests are performed, defects found are reported and added to the work items list, so they can be prioritized and assigned to team members.

Ongoing tasks

This activity includes tasks that happen throughout the iteration on an ongoing basis but are not necessarily part of a plan. For example, at any time, any role in the project team can issue a change request, either because there are requests for enhancements, or defects are found. These change requests are part of the work items list and are prioritized and assigned to team members. Anyone can be assigned to make changes that develop enhancements or fix defects.