Roadmap: How to Adopt the Risk-Value Lifecycle Practice |
This roadmap describes how to adopt the risk-value lifecycle practice. It helps prepare an organization to develop software guided by critical phases milestones, with the objective of mitigating project risks while increasing stakeholder value.
Main Description
### 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.
This program and the accompanying materials are made available under the Eclipse Public License V1.0, which accompanies this distribution. OpenUP Copyright