Getting started
Organize your project into a set of phases, each providing a milestone where business
and management decisions can be made on whether the project should go to the next
phase or not. A risk-value lifecycle provide stakeholders with visibility
on two main drivers: risks need to be driven down and value needs to
be driven up. At the end of each phase in the lifecycle, there is a
milestone that will help answer the questions and find the balance between risks
and value. See Phase Milestones for more information on milestones and Project Lifecycle for more information on balancing risks and value.
Divide phases into iterations that deliver an increment of software that you
can demonstrate and, potentially, deliver. Each iteration in a phase
will contain just enough of any activity required to meet the objectives of
that phase by the time you meet the milestone that concludes it. If the milestone
can't be satisfied, consider adding one more iteration to that phase until the
expected risks for the phase are mitigated or the expected stakeholder
value is provided.
Plan the number of iterations in each phase according to the lifecycle pattern
that is most appropriate to your project. For example, when the problem domain
is familiar, the risks are well-understood, and the project team is experienced,
you may need only one iteration in Inception and one in Elaboration phases,
then you can have multiple iterations in Construction (to develop
the requirements and architecture) and a few iterations in Transition to migrate
the product to users. Another example is when the problem domain is new
or unfamiliar or the team is inexperienced. In such a case, you might need several
iterations in Elaboration to refine requirements and architecture as you implement
them, then one iteration in Construction to deal with less critical requirements.
For more information on lifecycle patterns see [DOD94]
and [GIL88].
Phases are not identical in terms of schedule and effort. For example, a typical distribution of resources
and time spent for a medium-sized project is represented in the table below.
|
|
Inception
|
Elaboration
|
Construction
|
Transition
|
|
Effort
|
~5%
|
20%
|
65%
|
10%
|
|
Schedule
|
10%
|
30%
|
50%
|
10%
|
For more information and examples of projects adopting the four-phase lifecycle, see [KRO03].
Common pitfalls
A common misconception about the four unified process phases is to compare
them to a waterfall approach, where one would expect to document all of
the requirements in Inception, create the whole design and architecture in Elaboration,
do all of the implementation in Construction, and test in Transition. Phases
are time-allocated in the project schedule and provide a framework
and milestones for making business and management decisions. Each iteration
in each phase provides a complete pass through activities in the disciplines of
software development (for example, requirements, design, implementation, integration,
testing, and so on) and produces an executable increment of software that
minimizes risks and grows in value. |
