| <?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:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-vi8wxwxVZLY0SMPFxZjD7A" |
| name="new_concept,_lam4ADkBEduxovfWMDsntw" guid="-vi8wxwxVZLY0SMPFxZjD7A" changeDate="2007-05-24T11:34:55.636-0700"> |
| <mainDescription><h3>
 |
| What is an iteration
 |
| </h3>
 |
| <p>
 |
| An iteration is a set period of time within a project in which you produce a stable, executable version of the product,
 |
| together with any other supporting documentation, install scripts, or similar artifacts necessary to use this release. The
 |
| executable is demonstrable, allowing the team to demonstrate true progress to stakeholders, and get feedback on how they
 |
| are doing so that they can improve their understanding of what needs to be done and how to do it. 
 |
| </p>
 |
| <p> 
 |
| Each iteration
 |
| builds upon the results of the previous iteration, and will produce a product increment one step closer to the final
 |
| product. Iterations are timeboxed, meaning that the schedule for an iteration should be regarded as fixed, and the scope of
 |
| the iteration's content actively managed to meet that schedule.
 |
| </p>
 |
| <p>
 |
| At each iteration, artifacts are updated. It is said that this is a bit like "growing" software. Instead of developing
 |
| artifacts one after another, in a pipeline fashion, they are evolving across the cycle, although at different rates.
 |
| </p>
 |
| <p>
 |
| Iterative development is very disciplined: the iteration length is fixed, the objectives of iterations are carefully
 |
| planned, the evaluation criteria are established when each iteration is planned, and the tasks and responsibilities of
 |
| participants are well-defined. Additionally, objective measures of progress are captured. Some reworking takes place
 |
| from one iteration to the next, but this too is done in a structured fashion.
 |
| </p>
 |
| <p>
 |
| Each iteration should address the most critical risks, and implement the highest-priority Work Items. This ensures that
 |
| each iteration adds maximum stakeholder value, and reduces uncertainty. Iterative development is typically combined
 |
| with frequent or continuous integration: as unit-tested components become available, they are integrated, then a build
 |
| is produced and subjected to integration testing. In this way, the capability of the integrated software grows as the
 |
| iteration proceeds, towards the goals set when the iteration was planned. 
 |
| </p>
 |
| <p> 
 |
| Regular builds, such as daily or more
 |
| frequent builds, let you break down the integration and test issues and spread them across the development cycle. These
 |
| issues have often been the downfall of large projects, because all of the problems were discovered at once during the single
 |
| massive integration step, which occurred very late in the cycle, and where a single problem can halt the whole team.
 |
| </p>
 |
| <h3>
 |
| What Problem Do Iterations Address?
 |
| </h3>
 |
| <p>
 |
| Today’s software applications are too complex to allow you to sequentially define the requirements, come up with an
 |
| architecture and design, perform an implementation, carry out testing, and get it all right. With waterfall development, you
 |
| typically do not get meaningful feedback on what improvements can be made until it is so late in the project that it is
 |
| too costly to make them. 
 |
| </p>
 |
| <p>
 |
| By contrast, dividing the project into a series of time-boxed iterations allows you to deliver
 |
| capabilities that can be assessed by stakeholders at the end of each iteration. This approach provides rapid and timely
 |
| feedback loops, enabling issues to be addressed and improvements made at a lower cost, while budget and time still allow,
 |
| and before the project has gone so far ahead that major rework is required.
 |
| </p>
 |
| <h3>
 |
| Iteration Length
 |
| </h3>
 |
| <p>
 |
| Iterations are typically 4 weeks long, although some teams will work with iterations as short as a week or as long as
 |
| six weeks. For factors driving iteration length, see the following table. <br/>
 |
| </p>
 |
| 
 |
| <table style="WIDTH: 547px; HEIGHT: 356px" cellspacing="2" cellpadding="2" width="547" border="1">
 |
| <tbody>
 |
| <tr>
 |
| <th scope="col">
 |
| Factors leading to reduced iteration length 
 |
| </th>
 |
| <th scope="col">
 |
| Factors leading to increased iteration length
 |
| </th>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Small teams 
 |
| </td>
 |
| <td>
 |
| Large teams
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Co-located teams 
 |
| </td>
 |
| <td>
 |
| Distributed teams
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Strong configuration management system 
 |
| </td>
 |
| <td>
 |
| Poor configuration management system
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Dedicated, full-time resources
 |
| </td>
 |
| <td>
 |
| Matrixed or part-time resources
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Automated testing
 |
| </td>
 |
| <td>
 |
| Lack of automated testing
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Integrated tool environment 
 |
| </td>
 |
| <td>
 |
| Absence of good automation and tool integration
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Team experienced with iterative development
 |
| </td>
 |
| <td>
 |
| Team inexperienced with iterative development
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Fast decision making
 |
| </td>
 |
| <td>
 |
| Policies and bureaucracy preventing fast decision making
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Unclear requirements
 |
| </td>
 |
| <td>
 |
| Well-understood requirements
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Unclear or brittle architecture
 |
| </td>
 |
| <td>
 |
| Well-defined and stable architecture
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| New and poorly understood technology
 |
| </td>
 |
| <td>
 |
| Well-understood technology
 |
| </td>
 |
| </tr>
 |
| </tbody>
 |
| </table><br />
 |
| <br />
 |
| <h3>
 |
| Why Iterate?
 |
| </h3>
 |
| <p>
 |
| The iterative approach has proven itself superior to the waterfall approach for a number of reasons. See <a class="elementlinkwithusertext" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#KRO05" guid="_9ToeIB83Edqsvps02rpOOg">[KRO05]</a> for more details:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| You are more likely to build an application that addresses user needs, involve the customer in the development
 |
| project, and implement and validate the capabilities deemed most essential in each iteration.
 |
| </li>
 |
| <li>
 |
| Integration is not one “big bang” at the end of a project. Each iteration evolves executable code that is
 |
| continuously integrated to enable rapid feedback and minimize later revision.
 |
| </li>
 |
| <li>
 |
| Risks are usually discovered or addressed during early iterations. Implement the most essential capabilities
 |
| partially, and demonstrate them to key stakeholders to make sure that you are on the right track.
 |
| </li>
 |
| <li>
 |
| Your ability to work effectively is fine-tuned. During early iterations, team members are walking through all
 |
| lifecycle activities, which ensures that they have the tools, skills, organizational structure, and so on to work
 |
| effectively.
 |
| </li>
 |
| <li>
 |
| Management has a way of making tactical changes to the product. Iterative development allows you to evolve partial
 |
| implementations of the end product quickly, and use these for quick release of a reduced-scope product to counter a
 |
| competitor's move.
 |
| </li>
 |
| <li>
 |
| Reuse is facilitated. Discussions and reviews of the design in early iterations allow team members to spot
 |
| potential opportunities for reuse, and then develop a mature common code for these opportunities in subsequent
 |
| iterations.
 |
| </li>
 |
| <li>
 |
| Defects can be found and corrected over several iterations. Flaws are detected in early iterations, rather than
 |
| during a massive testing phase at the end. 
 |
| </li>
 |
| <li>
 |
| Project personnel are better used. An iterative process encourages widening the scope of expertise of the team
 |
| members, allowing them to play many roles, and thus enabling a project manager to make better use of the available
 |
| staff and simultaneously remove problematic handoffs.
 |
| </li>
 |
| <li>
 |
| Team members learn along the way. The project members have several opportunities within a development cycle to
 |
| learn from their mistakes and improve their skills from one iteration to another.
 |
| </li>
 |
| <li>
 |
| The development process itself is improved and refined along the way. The end of iteration assessment includes a
 |
| retrospective where the team identifies what can be improved in the next iteration in both the organization and the
 |
| process. 
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
