Concept: Elaboration Phase
Second of four phases in the project lifecycle, when architecturally-significant risks are addressed.
Main Description

Introduction

The purpose in this phase is to baseline the architecture of the system and provide a stable basis for the bulk of the development effort in the next phase.

There are objectives for the Elaboration phase that help us to address risks associated with requirements, architecture, costs and schedule [KRO03]:

  1. Get a more detailed understanding of the requirements. Having a good understanding of the vast majority of requirements allows you to create a more detailed plan and to get buy in from stakeholders. You want to gain an in-depth understanding of the most critical requirements to be validated by the architecture.
  2. Design, implement, validate, and baseline an architecture. Design, implement and test a skeleton structure of the system. Although the functionality is not complete yet, most of the interfaces between the building blocks are implemented and tested. This is referred to "an executable architecture".
  3. Mitigate essential risks, and produce accurate schedule and cost estimates. Many technical risks are addressed as result of detailing the requirements, and designing, implementing and testing the architecture. Refine and detail the coarse project plan.

The following table summarizes the Elaboration phase objectives and what activities address each objective:



Phase objectives

Activities addressing objectives

Get a more detailed understanding of the requirements

Manage Requirements

Design, implement, validate, and baseline an architecture

Define the Architecture
Develop Solution (for requirement)(within context)
Validate Build

Mitigate essential risks, and produce accurate schedule and cost estimates

Manage Iteration
Assess and Plan Next Iteration



Key Considerations

The number of iterations in Elaboration is dependent on - but not limited to - some factors like green-field development versus maintenance cycle, unprecedent system versus well-known technology and architecture, and so on.

Typically on the first iteration, you should design, implement and test a small number of critical scenarios to identify what type of architecture and architectural mechanisms you need, so you can mitigate the most crucial risks. You also detail high-risk requirements that have to be addressed early in the project. You test enough to validate that the architectural risks are mitigated.

On the following iterations, you fix whatever was not right from the previous iteration. You design, implement and test the remaining architecturally-significant scenarios, ensuring that you touch all major areas of the system (architectural coverage), so potential hidden risks arise as earlier as possible. [KRO03]