| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-R1d0qAJDnmI5Fm9ChHCYQw" |
| name="how_to_adopt,_ERIDQOMPEdyM47cGD2jiaQ" guid="-R1d0qAJDnmI5Fm9ChHCYQw" changeDate="2008-06-30T13:42:52.222-0700" |
| version="7.2.0"> |
| <mainDescription><h3> Getting started&nbsp; </h3>
 |
| 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&nbsp;provide stakeholders with visibility 
 |
| on two main drivers: risks need to be driven down and value&nbsp;needs&nbsp;to 
 |
| be&nbsp;driven up.&nbsp;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 <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/phase_milestones_5678231E.html" guid="_HNxbwMBJEdqSgKaj2SZBmg">Phase Milestones</a>&nbsp;for more information on milestones and <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle_203F87.html" guid="_nSfVwCNYEdyCq8v2ZO4QcA">Project Lifecycle</a>&nbsp;for more information on balancing risks and value.<br />
 |
| <p> Divide phases into iterations that deliver an increment of software that you 
 |
| can&nbsp;demonstrate and, potentially, deliver.&nbsp;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&nbsp;for the phase are mitigated or the expected stakeholder 
 |
| value is provided. </p>
 |
| <p> 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&nbsp;you can have multiple iterations in Construction&nbsp;(to develop 
 |
| the requirements and architecture) and a few iterations in Transition to migrate 
 |
| the product to users.&nbsp;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&nbsp;Construction to deal with less critical requirements. 
 |
| For more information on lifecycle patterns see&nbsp;[<a class="elementLinkWithUserText" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#DOD94" guid="_JlTPUM6aEdyuBO4ZIzcyig">DOD94</a>] 
 |
| and [<a class="elementLinkWithUserText" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#GIL88" guid="_JlTPUM6aEdyuBO4ZIzcyig">GIL88</a>].&nbsp; 
 |
| </p>
 |
| <p>
 |
| Phases are not identical in terms of schedule and effort. For example,&nbsp;a typical distribution&nbsp;of resources
 |
| and time spent for a medium-sized project is represented in the table below.
 |
| </p>
 |
| <table title="Typical distribution of schedule and effort on a mid-sized project" cellspacing="0" cellpadding="2" width="85%" border="1">
 |
| <tbody>
 |
| <tr>
 |
| <th id="" scope="col" abbr="">
 |
| </th>
 |
| <th id="" scope="col" abbr="">
 |
| Inception
 |
| </th>
 |
| <th id="" scope="col" abbr="">
 |
| Elaboration
 |
| </th>
 |
| <th id="" scope="col" abbr="">
 |
| Construction
 |
| </th>
 |
| <th id="" scope="col" abbr="">
 |
| Transition
 |
| </th>
 |
| </tr>
 |
| <tr>
 |
| <th id="" scope="row" abbr="">
 |
| Effort
 |
| </th>
 |
| <td>
 |
| ~5%
 |
| </td>
 |
| <td>
 |
| 20%
 |
| </td>
 |
| <td>
 |
| 65%
 |
| </td>
 |
| <td>
 |
| 10%
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <th id="" scope="row" abbr="">
 |
| Schedule
 |
| </th>
 |
| <td>
 |
| 10%
 |
| </td>
 |
| <td>
 |
| 30%
 |
| </td>
 |
| <td>
 |
| 50%
 |
| </td>
 |
| <td>
 |
| 10%
 |
| </td>
 |
| </tr>
 |
| </tbody>
 |
| </table>
 |
| <p>
 |
| For more information and examples of projects adopting the four-phase lifecycle, see [<a class="elementLinkWithUserText" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRO03" guid="_JlTPUM6aEdyuBO4ZIzcyig">KRO03</a>].
 |
| </p>
 |
| <h3> Common pitfalls </h3>
 |
| <p> A common misconception about the four unified process phases is to compare 
 |
| them to&nbsp;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&nbsp;time-allocated in the project schedule and&nbsp;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&nbsp;of 
 |
| software development (for example, requirements, design, implementation, integration, 
 |
| testing, and so on) and produces an executable&nbsp;increment of software&nbsp;that 
 |
| minimizes risks and grows in value. </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
