The iteration itself is a time-boxed set of tasks that are focused very
narrowly on producing an executable. For all but the last transition iteration
this is an intermediate product, produced to force attention on mitigating risk
and driving the project toward successful delivery. The focus on an executable
deliverable forces nearly continuous integration and allows the project to
address technical risks early, decreasing attendant risks.
Iterating implies a certain amount of rework (of existing artifacts), and an accompanying change in
attitude toward rework. In short, a certain amount of rework is required to
deliver a quality product: by building intermediate products and evaluating the
suitability of the product architecture early and often, the
quality of the end-product is increased while changes are less costly to make
and easier to accommodate.
Determine the Iteration Scope
Purpose
To select a set of use cases or scenarios to be considered during the
iteration.
To select a set of non-functional requirements which must be handled
during the iteration.
Guidelines:
The Iteration
Plan
The scope of an iteration is driven by four factors:
the top risks to the project
the functionality required of the system
the time allocated to the iteration in the Project Plan
the phase and its specific objectives (See Phases)
In the initial planning of an iteration, enough work is selected to fill the
time already planned for the iteration (which was based on considerations
explored in Guidelines: Software Development
Plan) - although the Project Manager is permitted some latitude to account
for resource constraints and other tactical considerations at the time the
Iteration Plan is being developed. Obviously, work planned for the previous
iteration, but not completed (because the previous iteration's scope was reduced
to meet the schedule) will normally have high priority.
The scope of work has also to be driven by a
sensible approach to the maximum staffing level that can be applied, in the
duration of the iteration, for its completion. For example, it is not usually
possible to double the work completed in an iteration by doubling the staff
applied to it - even if those resources were available. The approximate staff
numbers that can be efficiently applied are determined by overall software size
and architecture, and estimation models such as COCOMO II (see [BOE00])
can provide these.
The execution of an iteration is then managed by timeboxing
- that is, the scope and quality (in terms of discovered defects not rectified)
are actively managed to meet the end date.
In the elaboration phase:
[More info]
There are three main drivers for defining the objectives of an iteration in
elaboration:
Risk
Criticality
Coverage
The main driver to define iteration objectives are risks.
You need to mitigate or retire your risks as early as you can. This is mostly
the case in the elaboration phase, where most of your risks should be mitigated,
but this can continue to be a key elements in construction as some risks remain
high, or new risks are discovered. But since the goal of the elaboration phase
is to baseline an architecture, some other considerations have to come into
play, such as making sure that the architecture addresses all aspects of the
software to be developed (coverage). This is important since
the architecture will be used for further planning: organization of the team,
estimation of code to be developed, etc.
Finally, while focusing on risks is important, one should keep in mind what
are the primary missions of the system; solving all the hard issues is good, but
this must not be done in detriment of the core functionality: make sure that the
critical functions or services of the system are indeed covered (criticality),
even if there is no perceived risk associated with them.
From the Risk list, for the most damaging risks, identify some scenario in
some use case that would force the development team to "confront" the
risk.
Examples
if there is an integration risk such as "database D working
properly with OS Y", make sure you include one scenario that involves
some database interaction even very modest.
if there is a performance risk such as "time to compute the
trajectory of the aircraft", make sure you have one scenario that
includes this computation, at least for the most obvious and frequent
case.
For criticality, make sure that the most fundamental
function or services provided by the system are included. Select some scenario
out of the use case that represent the most common, the most frequent form of
the service or feature offered by the system. The Artifact:
Software Architecture Document is used to drive this effort, providing a
prioritized set of Use Cases or sub-flows of use cases to reflect the architecturally significant use cases or scenarios.
Example
for a telephone switch, the plain station-to-station call is the obvious
must for an early iteration. This is far more important to get right than
convoluted failure modes in operator configuration of the error handling
subsystem.
For coverage, towards the end of the elaboration
phase, include scenarios that touches areas that you know will require
development, although they are neither critical nor risky.
It is often economical to create long, end-to-end scenarios that address
multiple issues at once.
The danger is often to get the scenarios to be too "thick", i.e.,
trying to cover too many different aspects, and variants, and error cases (See Guidelines:
Iteration Plan)
Also, in the elaboration phase, keep in mind that some of the risks may be of
a more human or programmatic nature: team culture, training, selection of tools,
new techniques etc. and just going through the iteration is mitigating these risks.
Examples
Create one subscriber record on a client workstation, to be stored in
the database on the server, including user dialog, but not including all
field, and assuming no error is detected. Combines some critical function, with some integration risks
(database and communication software) and integration issues (dealing with 2
different platforms). Also force designers to become familiar with new GUI
design tool. Finally produces a prototype that can be demonstrated to
end-user for feedback.
Make sure up to 20,000 subscribers can be created, and access to one is
not longer than 200 milliseconds. Addresses some key performance issues (volume or data, and response
time), that may dramatically affect the architecture if not met.
Undo a change of subscriber address. A simple feature that forces designers to think about a design of
all "undo" functions. This may in turn trigger some push-back to
the end-users about what can be undone at reasonable cost.
Complete all the use cases relative to supply-chain management. The goal of the elaboration phase is also to complete the capture
of requirements, maybe also set by set.
In the construction phase:
[More info]
As the project moves into the construction phase, risks remain a key driver,
especially as new, unsuspected risks are uncovered. But completeness of use cases
start to be a driver. The iterations can be planned feature by feature, trying
to complete some of the most critical ones early so that they can be thoroughly
tested during more than one iteration. Towards the end of construction,
robustness of full use cases will be the main goal.
Example
Implement all variants of call forwarding, including erroneous ones. This is a set of related features. One of them may have been
implemented during the elaboration phase, and will serve as a prototype for
the rest of the development.
Complete all telephone operator features except night service. Another set of features.
Achieve 5,000 transactions per hour on a 2 computer set-up. This may step up the required performance relative to what was
actually achieved in the previous iteration (only 2,357/hour)
Integrate new version of Geographical Information System. This may be a modest architectural change, necessitated by some
problem discovered earlier.
Fix all level 1 and level 2 defects Fixes defects discovered during testing in the previous iteration
and not fixed immediately but deferred.
In the transition phase:
[More info]
Finishing this generation of the product is the main goal. Objective for an
iteration are set in terms of which bugs are fixed, which improvements in
performance or usability are included. If features had to be dropped (or
disabled) in order to get in time to the end of construction (IOC milestone, or
"beta"), they may now be completed, or turned on, if they do not
jeopardize what has been achieved so far.
Examples
Fix all severity 1 problems discovered on beta customer sites. A goal in term of quality, may be related to credibility on the
market.
Eliminate all startup crashes due to mismatched data. Another goal expressed in terms of quality.
Achieve 2,000 transactions per minute. Performance tuning, involving some optimization: data structure
change, caching and smarter algorithm.
Reduce the number of different dialog boxes by 30%. Improve usability by reducing the visual clutter
Produce German and Japanese versions. The beta was produced only for English customers by lack of time
and to reduce rework.
Define Iteration Evaluation Criteria
Each iteration results in an executable release. The release is not generally
production-quality (except in the final Transition iteration), but it can be
evaluated nonetheless.
Evaluating Inception
Iterations
The Inception iteration generally focuses on proving the concept of the
product and building the support necessary to approve project funding. As a
result, the Iteration release is generally a functional proof-of-concept
prototype which lacks real implementation code under a thin veneer of user
interface. The evaluation criteria are oriented toward user acceptance and
qualitative measures.
Under some circumstances, key technical hurdles must be overcome in inception
before product funding is provided; if so, the evaluation criteria must reflect
this.
See the evaluation
criteria for the inception phase.
Evaluating Elaboration
Iterations
Elaboration Iterations focus on creating a stable architecture. As a result,
Elaboration evaluation criteria must focus on assessing the stability of the
architecture. Measures that can be used are:
Interface stability (or breakage)
The rate of change in the Architecture (compared to an architectural
baseline)
performance of key functionality
The key goal is to ensure that changes during the Construction phase do not
ripple throughout the system, causing excessive re-work.
See the evaluation
criteria for the elaboration phase.
Evaluating Construction and Transition Iterations
Construction and Transition iterations are measured along traditional
software testing and change management dimensions such as breakage, defect
density, and fault discovery rates. The focus in these iterations is finding
errors so that they can be fixed.
Errors are discovered in a number of ways: inspections and code reviews,
functional tests, performance tests and load tests. Each technique is oriented
toward discovering a particular set of defects, and each has its place.
Specifics on these techniques are discussed in the Unified Process for EDUcation Test
discipline.
See the evaluation
criteria for the construction phase, and also see the evaluation
criteria for the transition phase.
Define Iteration Activities
Based upon the goals of the iteration, the set of activities to be performed
during the iteration must be selected. Typically, each iteration will make a
partial pass through all the activities in the software lifecycle:
Use cases and scenarios are selected which exercise the required
functionality
The use case (or scenario) behavior is researched and documented
The behavior is analyzed and allocated amongst subsystems and classes
which provide the required behavior
The classes and subsystems are designed, implemented and unit tested
The system is integrated and tested as a whole
For external releases (alpha, beta, and general availability) the product
is packaged into a releasable form and transitioned to into its user
environment.
The degree to which these activities are performed varies with the iteration
and the phase of the project. The individual disciplines (Requirements, Analysis
& Design, Test, etc.) define the generic activities, which in turn are
tailored to the organization during process configuration.
Identify affected artifacts and activities involved
Once the scenarios or full blown use cases to be developed (plus defects to
be fixed) have been selected and briefly sketched, you need to find what are the
artifacts that will be affected:
Which classes are to be revisited?
Which subsystems are affected, or even created?
Which interfaces are probably to be modified
Which documents have to be updated
Then extract from the process disciplines the activities that are involved, and
place them in your plan. Some activities are done once per iteration (example
here), some have to be done once per class, per use case, per subsystem
(example). Connect the activities with their obvious dependencies, and allocate
some estimated effort. Most of the activities described for the process are
small enough to be accomplished by one person, or a very small group of persons
in a matter of a few hours to a few days.
It is likely the case that you discover there is not enough time in the
iteration to accomplish all this. Rather than extending the iteration (hence
either extending the final delivery time, or reducing the number of iterations),
reduce the iteration ambitions. Depending on which phase you are in, make
scenarios simpler, eliminate or disable features.
Assign Responsibilities
Once the set of activities for the iteration have been defined, they must be
assigned to individual project team members. Depending on the staff resources
available and the scope of the iteration, the activities may either be carried
out by a single individual or a team. Reviews and Inspections are, of course,
inherently team activities. Other activities, such as authoring use cases or
designing and implementing classes, are inherently solitary (except in the case
where a junior team member may be teamed with a senior team member who acts as a
mentor).
In general, each work product must be the responsibility of a single
individual, even if the work is done by a team:
Use cases
Subsystems
Classes
Tests and test plans
etc.
Without a single point of contact, ensuring consistency becomes nearly
impossible.