<?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.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-vi8wxwxVZLY0SMPFxZjD7A" name="new_concept,_lam4ADkBEduxovfWMDsntw" guid="-vi8wxwxVZLY0SMPFxZjD7A" changeDate="2011-02-18T13:35:54.146-0800" version="7.2.0">
  <mainDescription>&lt;h3>&#xD;
    What is an Iteration&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    An iteration is a set period of time within a project in which you produce a stable, executable version of the product,&#xD;
    together with any other supporting documentation, install scripts, or similar, necessary to use this release. The&#xD;
    executable is demonstrable, allowing the team to demonstrate true progress to stakeholders, get feedback on how they&#xD;
    are doing so that they can improve their understanding of what needs to be done, and how to do it. Each iteration&#xD;
    builds upon the results of previous iteration, and will produce a product increment one step closer to the final&#xD;
    product. Iterations are timeboxed, meaning the schedule for an iteration should be regarded as fixed, and the scope of&#xD;
    the iteration's content actively managed to meet that schedule.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    At each iteration, artifacts are updated. It is said that this is a bit like &quot;growing&quot; software. Instead of developing&#xD;
    artifacts one after another, in a pipeline fashion, they are evolving across the cycle, although at different rates.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Iterative development is very disciplined: the iteration length is fixed; the objectives of iterations are carefully&#xD;
    planned; the evaluation criteria are established when each iteration is planned; and the tasks and responsibilities of&#xD;
    participants are well defined. Additionally, objective measures of progress are captured. Some reworking takes place&#xD;
    from one iteration to the next, but this too is done in a structured fashion.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Each iteration should address the most critical risks, and implement the highest-priority work items. This ensures that&#xD;
    each iteration adds maximum stakeholder value, while reducing uncertainty. Iterative development is typically combined&#xD;
    with frequent or continuous integration: as unit-tested components become available, they are integrated, then a build&#xD;
    is produced and subjected to integration testing. In this way, the capability of the integrated software grows as the&#xD;
    iteration proceeds, towards the goals set when the iteration was planned. Regular builds, such as daily or more&#xD;
    frequent builds, let you break down the integration and test issues and spread them across the development cycle. These&#xD;
    issues have often been the downfall of large projects because all problems were discovered at once during the single&#xD;
    massive integration step, which occurred very late in the cycle, and where a single problem halts the whole team.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Why Iterate&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The iterative approach has proven itself superior to the waterfall approach for a number of reasons:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        You are more likely to build an application that addresses user needs. Early specification of requirements often&#xD;
        leads to unused features. The Standish Group has researched thousands of application development projects and has&#xD;
        found that more than 45 percent of features are never used, while another 19 percent are used rarely&amp;nbsp; (see&#xD;
        Figure 2.3). In other words, typically more than half of the development effort is wasted on developing&#xD;
        nonessential capabilities. To avoid this problem, you need to involve the customer in the development project and&#xD;
        use an iterative approach that allows you to implement and validate the capabilities deemed most essential in each&#xD;
        iteration. This approach allows not only early validation of key capabilities but also addition of new capabilities&#xD;
        late in the project.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Integration is not one &quot;big bang&quot; at the end of a project. Leaving integration to the end results in time- and&#xD;
        budget-consuming rework. To avoid this, an iterative approach breaks a project down into smaller iterations, each&#xD;
        evolving executable code that is continuously integrated to enable rapid feedback and minimize later revision.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Risks are usually discovered or addressed during early iterations. With the iterative approach, risks are more&#xD;
        likely to be identified and addressed in early iterations. As an example, if there is a risk that a stakeholder&#xD;
        will not be happy with the functionality you are developing, iterative development will encourage you to&amp;nbsp;&#xD;
        implement the most essential capabilities partially and demonstrate them to key stakeholders to make sure that you&#xD;
        are on the right track.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Your ability to work effectively is fine-tuned. During early iterations, team members are walking through all&#xD;
        lifecycle activities, from requirements capture and test definition to development, implementation, and testing.&#xD;
        Consequently, they can make sure they have the tools, skills, organizational structure, and so on to work&#xD;
        effectively.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Management has a way of making tactical changes to the product. Management can make changes to the product along&#xD;
        the way-to compete with other new products, for example. Iterative development allows you to evolve partial&#xD;
        implementations of the end product quickly and use these for quick release of a reduced-scope product to counter a&#xD;
        competitor's move.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Reuse is facilitated. It is easier to identify common parts as they are being partially designed or implemented in&#xD;
        iterations than to recognize them at the beginning. Discussions and reviews of the design in early iterations allow&#xD;
        team members to spot potential opportunities for reuse and then develop a mature common code for these&#xD;
        opportunities in subsequent iterations.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Defects can be found and corrected over several iterations. This capability results in a robust architecture and a&#xD;
        high-quality application. Flaws are detected in early iterations, rather than during a massive testing phase at the&#xD;
        end. Performance bottlenecks are discovered while they can still be addressed instead of creating panic on the eve&#xD;
        of delivery.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Project personnel are better used. Many organizations match their use of a waterfall approach with a pipeline&#xD;
        organization: the analysts send the completed requirements to designers, who send a completed design to&#xD;
        programmers, who send components to integrators, who send a system to testers. These many handoffs are sources of&#xD;
        errors and misunderstandings and make people feel less responsible for the final product. An iterative process&#xD;
        encourages widening the scope of expertise of the team members, allowing them to play many roles and thus enabling&#xD;
        a project manager to make better use of the available staff and simultaneously remove problematic handoffs.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Team members learn along the way. The project members have several opportunities within a development cycle to&#xD;
        learn from their mistakes and improve their skills from one iteration to another. More training opportunities can&#xD;
        be discovered as a result of assessing the earlier iterations.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The development process itself is improved and refined along the way. The iteration assessment allows the team to&#xD;
        not only look at the project status from a product or scheduling perspective but also analyze what can be improved&#xD;
        in the next iteration in both the organization and the process.&amp;nbsp;One technique for doing so is to hold a&#xD;
        retrospective.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&lt;span class=&quot;E1&quot;>&lt;span&#xD;
style=&quot;FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA&quot;>&lt;strong>&lt;img&#xD;
 height=&quot;307&quot; alt=&quot;45 percent of features implemented are never ever used&quot; src=&quot;./resources/iteration.gif&quot;&#xD;
width=&quot;489&quot; />&lt;/strong>&lt;/span>&lt;/span>&amp;nbsp; &#xD;
&lt;p>&#xD;
    &lt;strong>&lt;em>Figure 2.3. Most Features Implemented Are Never or Rarely Used.&lt;br />&#xD;
    &lt;/em>&lt;/strong>&lt;em>According to the Standish Group, an amazing 45 percent of features implemented are never used, while&#xD;
    another 19 percent are used only rarely. If features never used were not implemented in the first place, development&#xD;
    time would be cut in about half. Further, since productivity is typically measured in the form of lines of code or&#xD;
    functionality delivered, this improvement would not register as a productivity increase using standard productivity&#xD;
    measures.&lt;/em>&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Iteration Length&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Iterations are typically 4 weeks long, although some teams will work with iterations as short as a week or as long as&#xD;
    six weeks. For factors driving iteration length, see Table 1.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>&lt;em>Table 1. Factors Impacting Iteration Length.&lt;/em>&lt;/strong>&#xD;
&lt;/p>&lt;br />&#xD;
&lt;br />&#xD;
&lt;table style=&quot;WIDTH: 547px; HEIGHT: 356px&quot; cellspacing=&quot;2&quot; cellpadding=&quot;2&quot; width=&quot;547&quot; border=&quot;1&quot;>&#xD;
    &lt;tbody>&#xD;
        &lt;tr>&#xD;
            &lt;th scope=&quot;col&quot;>&#xD;
                Factors leading to reduced iteration length&amp;nbsp;&#xD;
            &lt;/th>&#xD;
            &lt;th scope=&quot;col&quot;>&#xD;
                Factors leading to increased iteration length&#xD;
            &lt;/th>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Small teams&amp;nbsp;&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Large teams&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Co-located teams&amp;nbsp;&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Distributed teams&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Strong configuration management system&amp;nbsp;&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Poor configuration management system&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Dedicated, full-time resources&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Matrixed or part-time resources&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Automated testing&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Lack of automated testing&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Integrated tool environment&amp;nbsp;&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Absence of good automation and tool integration&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Team experienced with iterative development&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Team inexperienced with iterative development&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Fast decision making&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Policies and bureaucracy preventing fast decision making&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Unclear requirements&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Well-understood requirements&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Unclear or brittle architecture&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Well-defined and stable architecture&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                New and poorly understood technology&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Well-understood technology&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
    &lt;/tbody>&#xD;
&lt;/table>&lt;br />&#xD;
&lt;br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
