Getting Started
Organize your project into a set of phases, each providing a milestone where business and management decision can be
made on whether the project should go or not to the next phase. 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 a demo-able, potentially shippable increment of software. Each
iteration on 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 only need one iteration in Inception and one in Elaboration phases, then 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 the requirements in Inception, create the whole design and architecture in Elaboration, do
all the implementation in Construction, and testing in Transition. Phases are time allocated in the project
schedule, and provide a framework and milestones for business and management decisions to be made. Each iteration
in each phase provides a complete pass through activities in the disciplines of software development (i.e.
requirements, design, implementation, integration, testing, and so on) and produces an executable increment of
software that minimizes risks and grows in value.
|
