<?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:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-vi8wxwxVZLY0SMPFxZjD7A" name="new_concept,_lam4ADkBEduxovfWMDsntw" guid="-vi8wxwxVZLY0SMPFxZjD7A" changeDate="2007-05-24T22:04:55.636+0330">
  <mainDescription>&lt;h1>&#xD;
    What is an iteration&#xD;
&lt;/h1>&#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 artifacts necessary to use this release. The&#xD;
    executable is demonstrable, allowing the team to demonstrate true progress to stakeholders, and 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. &#xD;
&lt;/p>&#xD;
&lt;p>	&#xD;
	Each iteration&#xD;
    builds upon the results of the previous iteration, and will produce a product increment one step closer to the final&#xD;
    product. Iterations are timeboxed, meaning that 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, and reduces 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. &#xD;
&lt;/p>&#xD;
&lt;p>	&#xD;
	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 of the problems were discovered at once during the single&#xD;
    massive integration step, which occurred very late in the cycle, and where a single problem can halt the whole team.&#xD;
&lt;/p>&#xD;
&lt;h1>&#xD;
    What Problem Do Iterations Address?&#xD;
&lt;/h1>&#xD;
&lt;p>&#xD;
    Today’s software applications are too complex to allow you to sequentially define the requirements, come up with an&#xD;
    architecture and design, perform an implementation, carry out testing, and get it all right. With waterfall development, you&#xD;
    typically do not get meaningful feedback on what improvements can be made until it is so late in the project that it is&#xD;
    too costly to make them. &#xD;
	&lt;/p>&#xD;
&lt;p>&#xD;
	By contrast, dividing the project into a series of time-boxed iterations allows you to deliver&#xD;
    capabilities that can be assessed by stakeholders at the end of each iteration. This approach provides rapid and timely&#xD;
    feedback loops, enabling issues to be addressed and improvements made at a lower cost, while budget and time still allow,&#xD;
    and before the project has gone so far ahead that major rework is required.&#xD;
&lt;/p>&#xD;
&lt;h1>&#xD;
    Iteration Length&#xD;
&lt;/h1>&#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 the following table. &lt;br/>&#xD;
&lt;/p>&#xD;
&#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 &#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 &#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 &#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 &#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 &#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 />&#xD;
&lt;h1>&#xD;
    Why Iterate?&#xD;
&lt;/h1>&#xD;
&lt;p>&#xD;
    The iterative approach has proven itself superior to the waterfall approach for a number of reasons. See &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#KRO05&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[KRO05]&lt;/a> for more details:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        You are more likely to build an application that addresses user needs, involve the customer in the development&#xD;
        project, and implement and validate the capabilities deemed most essential in each iteration.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Integration is not one “big bang” at the end of a project. Each iteration evolves executable code that is&#xD;
        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. Implement the most essential capabilities&#xD;
        partially, and demonstrate them to key stakeholders to make sure that you 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, which ensures that 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. 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. Discussions and reviews of the design in early iterations allow team members to spot&#xD;
        potential opportunities for reuse, and then develop a mature common code for these opportunities in subsequent&#xD;
        iterations.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Defects can be found and corrected over several iterations. Flaws are detected in early iterations, rather than&#xD;
        during a massive testing phase at the end. &#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Project personnel are better used. An iterative process encourages widening the scope of expertise of the team&#xD;
        members, allowing them to play many roles, and thus enabling a project manager to make better use of the available&#xD;
        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.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The development process itself is improved and refined along the way. The end of iteration assessment includes a&#xD;
        retrospective where the team identifies what can be improved in the next iteration in both the organization and the&#xD;
        process. &#xD;
    &lt;/li>&#xD;
&lt;/ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
