primary purpose of this phase is to complete the most essential parts of the
project that are high risk and plan the construction phase. This is the part of
the project where technical risk is fully evaluated and/or eliminated by
building the highest risk parts of the project. During this phase personnel
requirements should be more accurately determined along with estimated man
hours to complete the project.
complete cost and time frame of the project is more firmly determined. During
this phase how the system will work must be considered. Use cases will help
identify risks. Steps to take during this phase:
project plan with construction iterations planned with requirements for each
of use cases are completed. Significant use cases are described in detail.
project domain model is defined. (Don't get bogged down)
use cases by priority and risk. Do the highest priority and highest risk use
cases first. Items that may be high risk:
-Overall system architecture especially
when dealing with communication between subsystems.
-Anything not done before or used before
such as a new programming language, or using the unified/iterative process for
the first time.
design and development of the riskiest and highest priority use cases. There
will be an iteration for each high risk and priority use case.
the iterations for the construction phase. This involves choosing the length of
the iterations and deciding which use cases or parts of use cases will be
implemented during each iteration. Develop the higher priority and risk use
cases during the first iterations in the construction phase.
was done on a preliminary level in the previous phase, the value (priority) of
use cases and their respective risks must be more fully assessed in this phase.
This may be done be either assigning an number to each use case for both value
and risk. or categorize them by high, medium, or low value and risk. Time
required for each use case should be estimated to the man week. Do the highest
priority and highest risk use cases first.
Requirements to be completed for this
of the software architecture. Therefore most use cases should be done, activity
diagrams, state charts, system sequence diagrams, and the domain model should
be mostly complete.
prototype that overcomes the greatest project technical risk and has minimal
high priority functionality.
may be an elaboration phase for each high risk use case.
the various diagrams and charts to be created, when they are created, and the
best order to create them in, there seems to be a variety of opinions. This is
because in the real world there may be more than one correct solution and there
are no hard and fast rules that work everytime. In a way, this flexibility is a
strength of UML.
documentation indicates that most use cases should be done before creating a
domain model and others indicate that the domain model can be built on a use
case by use case basis. A good compromise is to spend a short time on a brief
domain model during the elaboration phase, then enhance the domain model as
each use case is developed during the elaboration and construction phase
documentation indicates that activity diagrams and class diagrams should be
complete before the domain model is done. It is possible to create some of the
diagrams and charts (artifacts) in parallel with each otherCompletion of 80% of
use case diagrams.
of 80% of high level use case diagrams.
of expanded use case diagrams for major use cases only.
sequence diagrams for major use cases
model (Don't get bogged down here with details). Just get a good idea of
concepts involved. Use use cases to create the domain model. Any use case that
strongly impacts the domain model should be considered and concepts from that
use case should be incorporated in the domain model. The initial domain model
may be drawn without lines and attributes to avoid too much detail and
determine important use cases. The domain model may be refined later as the
project analysis continues. If the system is large, domain models should be
done on a per use case basis.
create a glossary of terms for concepts to improve team communication
this point the design part of the project begins (although more analysis is
done for each use case) and the following will be done in each iteration of the
elaboration and construction phases.
contracts based on domain model and use cases.
class and collaboration diagrams to code.
the domain model but do not force it to the class diagrams. Considerations
during this project should be the following:
possible significant changes (down the road) to the system during analysis.
system functional ability what do you expect to be able to change?
phase plans the necessary activities and required resources and specifies the
features and designing the architecture.
Things to do: With the input of the use
case model generated from the previous phase, we transform it into a design
model via an analysis model. In brief, both an analysis model and a design
model are structures made up of classifiers and a set of use-case realizations
that describe how this structure realizes the use cases. Classifiers are, in
general, "class-like" things.
analysis model is a detailed specification of the requirements and works as a
first cut at a design model, although it is a model of its own. It is used by
developers to understand precisely the use cases as described in the
requirements. The analysis model is different from the design model in that it
is a conceptual model rather than a blueprint of the implementation.
A detailed software development plan,
updated risk assessment
phase plan showing the number and contents of the iteration
iterative plan, detailing the next iteration
development environment and other tools required
baseline vision, in the form of a set of evalution criteria for the final
measurable evalution criteria for assessing the results of the initial
iterations of the construction phase
domain analysis model (80% complete), sufficient to be able to call the
corresponding architecture 'complete'.
software architecture description (stating constraints and limitations)
executable architectural baseline.
the Elaboration phase the project team is expected to capture a healthy
majority of the system requirements. However, the primary goals of Elaboration
are to address known risk factors and to establish and validate the system
architecture. Common processes undertaken in this phase include the creation of
use case diagrams, conceptual diagrams (class diagrams with only basic
notation) and package diagrams (architectural diagrams).
architecture is validated primarily through the implementation of an Executable
Architecture Baseline. This is a partial implementation of the system which
includes the core, most architecturally significant, components. It is built in
a series of small, timeboxed iterations. By the end of the Elaboration phase
the system architecture must have stabilized and the executable architecture
baseline must demonstrate that the architecture will support the key system
functionality and exhibit the right behavior in terms of performance,
scalability and cost.
final Elaboration phase deliverable is a plan (including cost and schedule
estimates) for the Construction phase. At this point the plan should be
accurate and credible, since it should be based on the Elaboration phase
experience and since significant risk factors should have been addressed during
the Elaboration phase.
Lifecycle Architecture Milestone marks the end of the Elaboration phase.