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.
|