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]:
-
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.
-
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".
-
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:
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]
|