The Iteration Planning Process

I l @ ve RuBoard

The iteration release plan prescribes schedules for all the increments of the system. "Such a plan must identify a controlled series of architectural releases, each growing in its functionality and ultimately encompassing the requirements of the complete production system." ^[1]

^[1] Booch, Grady. Object Solutions . Redwood City, CA: Addison-Wesley, 1995.

"The iteration plan must state the iteration specific goals:

• Capabilities being developed

• Risks being mitigated during this iteration

• Defects being fixed during the iteration

Exit criteria:

• Updated capability information

• Updated risk mitigation plan

• A release description document, which captures the results of an iteration

• Test cases and results of the tests conducted on the products including a list of defects

• An iteration plan, detailing the next iteration including measurable evaluation criteria for assessing the results of the next iteration(s)" ^[2]

  ^[2] Kruchten, Philippe. A Rational Development Process . Rational Software Corporation. Available at www.rational.com.

^[2] Kruchten, Philippe. A Rational Development Process . Rational Software Corporation. Available at www.rational.com.

The scenarios developed during analysis are the main input to this phase of development. The scenarios are examined and prioritized according to risk, importance to the customer, and the need to develop certain basic scenarios first. This task is best accomplished with a team made up of a domain expert, analysts, the architect, and testing personnel. "Scenarios should be grouped so that for each release, they collectively provide a meaningful chunk of the system's behavior and additionally require the development team to attack the project's next highest risks." ^[3] As each iteration is completed, risks are reevaluated and the project plan is updated as needed. "For most projects, plan on about five (plus or minus two) intermediate releases." ^[4]

^[3] Booch, Grady. Object Solutions . Redwood City, CA: Addison-Wesley, 1995.

^[4] Ibid .

The iteration planning process is shown in Figure 12-1.

Figure 12-1. Iteration Planning Process

ESU Course Registration Problem Iteration Plan

For the ESU Course Registration problem the iteration plan is as follows :

• Iteration 1

  Maintain professor information

  Select courses to teach

  Maintain curriculum

• Iteration 2

  Maintain student information

  Generate catalog

• Iteration 3

  Register for courses

  Request class roster

Iteration 1 addresses the database risk ”the courses must be stored in a database that is accessible to all. The Maintain Professor Info and Select Courses to Teach scenarios are in this iteration since they must be completed before the catalog can be generated. Iteration 2 adds the functionality needed to register a student (the student information must be in the database and the catalog must be available for the students). Iteration 3 completes the system.

I l @ ve RuBoard