iteration_summary
An Iteration-N Scope summary describes a primary unit of development that
enables incremental and iterative steps (i.e. Iteration-N) in a project.
Each incremental iteration allows new requirements to be addressed while
existing requirements are revisited.
The goal is to achieve a working system early in the development cycle.
This system is continually refined and extended over successive development
passes.
Once the initial architecture and core use-cases are laid down, work is
typically geared around adding more detail to the system by iterating over
it.
This document is about the who, what, why, how, when, and where of an
incremental iteration. The initial document comes from Wayne Parrott
who is a CORBA, Smalltalk, Java consultant. He may be reached at
wayne@workingobjects.com.
This section includes a brief overview of the iteration's purpose, significance,
its duration, and the personnel involved and their expected level of effort.
The reader should get a feel for the scope and significance of the iteration
with respect to the project overall.
This section defines the requirements to be addressed during the iteration.
Requirements are categorized as either functional or non-functional. Functional
requirements are structured as use-cases and use-case scenarios. Non-functional
requirements, such as performance, programming language usage, technology
utilization, etc., are also listed.
Assign each requirement a priority of A, B, or C.
Restrict use of the A priority to those requirements that absolutely must
be completed during the iteration for it to be judged a success.
B priority requirements should be ranked and addressed after the A priority
tasks.
C priority tasks are usually bumped from the iteration scope.
List the use-cases and scenarios to be addressed during the iteration.
Include a brief description and qualify the expected level of completion.
List non-use-case development activities such as the development of frameworks,
architectural elements, optimization, reuse, etc.
State the acceptance criteria for each task.
Identify risks and contingencies. The primary concern should be if an A priority
task gets blown.
Keep iterations short (small) and well focused. Clearly, define the
Analysis/Design/Iteration/Test/Documentation tasks in the schedule.
Organizations report:
<![CDATA[
Refining a working system gives early feedback to developers
Acceptance criterion and risks are identified early
Iteration encourages refinement of foundation classes
Software refinement enables testable software interfaces
Test cases grow into regression test suites
]]>