OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/concepts/iteration.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>\openup_basic\guidances\concepts\iteration.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: iteration.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_lam4ADkBEduxovfWMDsntw CRC: 1814057918 -->Iteration<!-- END:presentationName,_lam4ADkBEduxovfWMDsntw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_lam4ADkBEduxovfWMDsntw CRC: 2358982076 -->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, necessary to use this release. Also referred to as a cycle or a timebox.<!-- END:briefDescription,_lam4ADkBEduxovfWMDsntw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-vi8wxwxVZLY0SMPFxZjD7A CRC: 2553426250 --><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, necessary to use this release. The executable is demonstrable, allowing the team to demonstrate true progress to stakeholders, 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, Each iteration builds upon the results of previous iteration, and will produce a product increment one step closer to the final product. Iterations are timeboxed, meaning 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, while reducing 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. 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 problems were discovered at once during the single massive integration step, which occurred very late in the cycle, and where a single problem halts 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, do an implementation, carry out testing, and get it all right. Whether you use waterfall or iterative development approaches, your initial requirements, architecture, design, and code will be suboptimal. 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. 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 Table X. </P>
 <P><STRONG><EM>Table X. Factors Impacting Iteration Length.</EM></STRONG><BR>&nbsp;<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&nbsp; </TH>
 <TH scope=col>Factors leading to increased iteration length </TH></TR>
 <TR>
 <TD>Small teams&nbsp; </TD>
 <TD>Large teams </TD></TR>
 <TR>
 <TD>Collocated teams&nbsp; </TD>
 <TD>Distributed teams </TD></TR>
 <TR>
 <TD>Strong configuration management system&nbsp; </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&nbsp; </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: </P>
 <UL>
 <LI>You are more likely to build an application that addresses user needs. Early specification of requirements often leads to unused features. The Standish Group has researched thousands of application development projects and has found that more than 45 percent of features are never used, while another 19 percent are used rarely&nbsp; (see Figure 2.3). In other words, typically more than half of the development effort is wasted on developing nonessential capabilities. To avoid this problem, you need to involve the customer in the development project and use an iterative approach that allows you to implement and validate the capabilities deemed most essential in each iteration. This approach allows not only early validation of key capabilities but also addition of new capabilities late in the project.
 <LI>Integration is not one “big bang” at the end of a project. Leaving integration to the end results in time- and budget-consuming rework. To avoid this, an iterative approach breaks a project down into smaller iterations, each evolving executable code that is continuously integrated to enable rapid feedback and minimize later revision.
 <LI>Risks are usually discovered or addressed during early iterations. With the iterative approach, risks are more likely to be identified and addressed in early iterations. As an example, if there is a risk that a stakeholder will not be happy with the functionality you are developing, iterative development will encourage you to&nbsp; implement the most essential capabilities partially and demonstrate them to key stakeholders to make sure that you are on the right track.
 <LI>Your ability to work effectively is fine-tuned. During early iterations, team members are walking through all lifecycle activities, from requirements capture and test definition to development, implementation, and testing. Consequently, they can make sure they have the tools, skills, organizational structure, and so on to work effectively.
 <LI>Management has a way of making tactical changes to the product. Management can make changes to the product along the way—to compete with other new products, for example. 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>Reuse is facilitated. It is easier to identify common parts as they are being partially designed or implemented in iterations than to recognize them at the beginning. 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>Defects can be found and corrected over several iterations. This capability results in a robust architecture and a high-quality application. Flaws are detected in early iterations, rather than during a massive testing phase at the end. Performance bottlenecks are discovered while they can still be addressed instead of creating panic on the eve of delivery.
 <LI>Project personnel are better used. Many organizations match their use of a waterfall approach with a pipeline organization: the analysts send the completed requirements to designers, who send a completed design to programmers, who send components to integrators, who send a system to testers. These many handoffs are sources of errors and misunderstandings and make people feel less responsible for the final product. 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>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. More training opportunities can be discovered as a result of assessing the earlier iterations.
 <LI>The development process itself is improved and refined along the way. The end of iteration assessment not only looks at the project status from a product or scheduling perspective but also analyzes what can be improved in the next iteration in both the organization and the process.&nbsp; One technique for doing so is to hold a retrospective. </LI></UL><BR><SPAN class=E1><SPAN style="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"><?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><v:shapetype id=_x0000_t75 stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><STRONG><IMG height=307 alt="45 percent of featues implemented are never ever used" src="./resources/iteration_1.GIF" width=489></STRONG></v:shapetype></SPAN></SPAN><BR>&nbsp;
 <P><STRONG><EM>Figure 2.3. Most Features Implemented Are Never or Rarely Used.<BR></EM></STRONG><EM>An amazing 45 percent of features implemented are never used, while another 19 percent are used only rarely. If features never used were not implemented in the first place, development time would be cut in about half. Further, since productivity is typically measured in the form of lines of code or functionality delivered, this improvement would not register as a productivity increase using standard productivity measures.<BR></EM>&nbsp; </P>
 <H3>Iteration and Phases </H3>
 <P>The purpose of iterations is to produce an executable which can be assessed so you can get feedback and make course corrections. This executable brings you one step closer to the final product. Phases provide a focus for a team on meeting a certain management objective. OpenUP has four phases, each ending with answering a specific question: </P>
 <UL>
 <LI><STRONG>Inception</STRONG>—Do we agree on the problem we are trying to solve?
 <LI><STRONG>Elaboration</STRONG>—Do we agree on the overall solution, and do we understand risks, costs and schedule parameters reasonably well?
 <LI><STRONG>Construction</STRONG>—Do we agree that we have a system that addresses key stakeholder needs?
 <LI><STRONG>Transition</STRONG>—Do we agree that we can release the system and end the project? </LI></UL>
 <P>Within each phase, you may have one or several iterations, where the iterations aim at producing the results required to answer these questions. As an example, to answer the question for Elaboration, we typically need to implement and test some key aspects of the system so that we understand what architecture we need, what Commercial Off-The-Shelf (COTS) components we may need, what key risks we face and how to address them, the effectiveness of the team, and so on. These needs will steer how we prioritize what is to be done in an Elaboration iteration. </P><!-- END:mainDescription,-vi8wxwxVZLY0SMPFxZjD7A -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>\openup_basic\guidances\concepts\iteration.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: iteration.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_lam4ADkBEduxovfWMDsntw CRC: 1814057918 -->Iteration<!-- END:presentationName,_lam4ADkBEduxovfWMDsntw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_lam4ADkBEduxovfWMDsntw CRC: 2358982076 -->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, necessary to use this release. Also referred to as a cycle or a timebox.<!-- END:briefDescription,_lam4ADkBEduxovfWMDsntw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-vi8wxwxVZLY0SMPFxZjD7A CRC: 2553426250 --><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, necessary to use this release. The executable is demonstrable, allowing the team to demonstrate true progress to stakeholders, 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, Each iteration builds upon the results of previous iteration, and will produce a product increment one step closer to the final product. Iterations are timeboxed, meaning 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, while reducing 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. 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 problems were discovered at once during the single massive integration step, which occurred very late in the cycle, and where a single problem halts 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, do an implementation, carry out testing, and get it all right. Whether you use waterfall or iterative development approaches, your initial requirements, architecture, design, and code will be suboptimal. 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. 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 Table X. </P>
	<P><STRONG><EM>Table X. Factors Impacting Iteration Length.</EM></STRONG><BR> <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>Collocated 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: </P>
	<UL>
	<LI>You are more likely to build an application that addresses user needs. Early specification of requirements often leads to unused features. The Standish Group has researched thousands of application development projects and has found that more than 45 percent of features are never used, while another 19 percent are used rarely  (see Figure 2.3). In other words, typically more than half of the development effort is wasted on developing nonessential capabilities. To avoid this problem, you need to involve the customer in the development project and use an iterative approach that allows you to implement and validate the capabilities deemed most essential in each iteration. This approach allows not only early validation of key capabilities but also addition of new capabilities late in the project.
	<LI>Integration is not one “big bang” at the end of a project. Leaving integration to the end results in time- and budget-consuming rework. To avoid this, an iterative approach breaks a project down into smaller iterations, each evolving executable code that is continuously integrated to enable rapid feedback and minimize later revision.
	<LI>Risks are usually discovered or addressed during early iterations. With the iterative approach, risks are more likely to be identified and addressed in early iterations. As an example, if there is a risk that a stakeholder will not be happy with the functionality you are developing, iterative development will encourage you to  implement the most essential capabilities partially and demonstrate them to key stakeholders to make sure that you are on the right track.
	<LI>Your ability to work effectively is fine-tuned. During early iterations, team members are walking through all lifecycle activities, from requirements capture and test definition to development, implementation, and testing. Consequently, they can make sure they have the tools, skills, organizational structure, and so on to work effectively.
	<LI>Management has a way of making tactical changes to the product. Management can make changes to the product along the way—to compete with other new products, for example. 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>Reuse is facilitated. It is easier to identify common parts as they are being partially designed or implemented in iterations than to recognize them at the beginning. 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>Defects can be found and corrected over several iterations. This capability results in a robust architecture and a high-quality application. Flaws are detected in early iterations, rather than during a massive testing phase at the end. Performance bottlenecks are discovered while they can still be addressed instead of creating panic on the eve of delivery.
	<LI>Project personnel are better used. Many organizations match their use of a waterfall approach with a pipeline organization: the analysts send the completed requirements to designers, who send a completed design to programmers, who send components to integrators, who send a system to testers. These many handoffs are sources of errors and misunderstandings and make people feel less responsible for the final product. 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>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. More training opportunities can be discovered as a result of assessing the earlier iterations.
	<LI>The development process itself is improved and refined along the way. The end of iteration assessment not only looks at the project status from a product or scheduling perspective but also analyzes what can be improved in the next iteration in both the organization and the process.  One technique for doing so is to hold a retrospective. </LI></UL><BR><SPAN class=E1><SPAN style="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"><?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><v:shapetype id=_x0000_t75 stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><STRONG><IMG height=307 alt="45 percent of featues implemented are never ever used" src="./resources/iteration_1.GIF" width=489></STRONG></v:shapetype></SPAN></SPAN><BR>
	<P><STRONG><EM>Figure 2.3. Most Features Implemented Are Never or Rarely Used.<BR></EM></STRONG><EM>An amazing 45 percent of features implemented are never used, while another 19 percent are used only rarely. If features never used were not implemented in the first place, development time would be cut in about half. Further, since productivity is typically measured in the form of lines of code or functionality delivered, this improvement would not register as a productivity increase using standard productivity measures.<BR></EM>  </P>
	<H3>Iteration and Phases </H3>
	<P>The purpose of iterations is to produce an executable which can be assessed so you can get feedback and make course corrections. This executable brings you one step closer to the final product. Phases provide a focus for a team on meeting a certain management objective. OpenUP has four phases, each ending with answering a specific question: </P>
	<UL>
	<LI><STRONG>Inception</STRONG>—Do we agree on the problem we are trying to solve?
	<LI><STRONG>Elaboration</STRONG>—Do we agree on the overall solution, and do we understand risks, costs and schedule parameters reasonably well?
	<LI><STRONG>Construction</STRONG>—Do we agree that we have a system that addresses key stakeholder needs?
	<LI><STRONG>Transition</STRONG>—Do we agree that we can release the system and end the project? </LI></UL>
	<P>Within each phase, you may have one or several iterations, where the iterations aim at producing the results required to answer these questions. As an example, to answer the question for Elaboration, we typically need to implement and test some key aspects of the system so that we understand what architecture we need, what Commercial Off-The-Shelf (COTS) components we may need, what key risks we face and how to address them, the effectiveness of the team, and so on. These needs will steer how we prioritize what is to be done in an Elaboration iteration. </P><!-- END:mainDescription,-vi8wxwxVZLY0SMPFxZjD7A -->
	</body>
	</html>