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.
The scope of an iteration is driven by four factors:
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:
There are three main drivers for defining the objectives of an iteration in elaboration:
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.
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.
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.
In the construction phase:
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.
In the transition phase:
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.
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.
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.
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:
The key goal is to ensure that changes during the Construction phase do not ripple throughout the system, causing excessive re-work.
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.
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:
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:
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.
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:
Without a single point of contact, ensuring consistency becomes nearly