Artifacts > Project Management Artifact Set > Software Development Plan > Guidelines
We have defined an iteration as a rather complete mini-project, going through all major disciplines and resulting in most cases in an executable, yet incomplete, system: a release. Although the cycle [edit, compile, test, debug] sounds like an iteration, this is not what we mean here. The daily or weekly builds incrementally integrating and testing more and more elements of the system may also seem to be an iteration, but that is only a portion of an iteration, as we use the term here.
An iteration starts with planning and requirements, and ends with a release, internal or external.
How quickly you can iterate depends mostly on the size of the development organization.
Other factors come into play: the degree of familiarity of the organization with the iterative approach, including having a stable and mature organization, the level of automation the team is using to manage code (for example, distributed CM), distribute information (for example, internal web), automate testing, and so on.
Be aware also that there is some fixed overhead in an iteration, in planning, synchronizing, analyzing the results, and so on.
So, on one hand, convinced by the tremendous benefits of the iterative approach, you might be tempted to iterate furiously, the human limits of your organization are going to slow your fervor.
Some empirical data::
Once you have an idea of the number of iterations in your coarse-grained plan, you need to define the contents of each iteration. It is even a good idea to find a name or title to qualify the product you have at the end of each iteration, to help people get a better focus.
A very simple project may have only one iteration per phase:
For a more substantial project, in its initial development cycle the norm would be:
For a large project, with lots of unknowns, new technologies, and the like, there may be a case for:
So over a development cycle, we have:
So, in general, plan to have three to ten iterations. Observe though that the upper and lower bounds connote unusual circumstances, so most developments will use six to eight iterations.
Many variations are possible depending on risks, size, complexity:
The default review sequence for a waterfall life-cycle project has a single major review at the completion of the important artifacts, for example:
In the Rational Unified Process (RUP), parts of the equivalent artifacts are reviewed as they are completed in each iteration, but the major milestones (and therefore reviews) are aligned with the completion of the phases, inception, elaboration, construction and transition. A Project Manager wanting to adopt the RUP may have to find a way to reconcile this apparent conflict, because of contractual obligations. Ideally, the Project Manager should convince the customer that the phase and iteration based approach in fact gives greater true visibility into project progress, and reduces risk, so that there is no need for an SRR, an SSR, and so forth. However, this is not always possible, and the Project Manager has to schedule these reviews at appropriate points. It is possible, in the RUP, to locate the points at which these important artifacts (actually, their equivalents in the RUP) are essentially complete, although this does not always neatly align with phases or iterations.
This is done here by assuming that the relative effort that will be spent on requirements, design, and the like will be approximately the same in the RUP as in the (ideal) waterfall life cycle - but that the effort will be distributed differently. The result is the following:
For efficiency, the Project Manager, in consultation with the customer, should attempt to combine these reviews with the prescribed RUP reviews. This is clearly possible for the SRR and the PDR, they can be combined with Lifecycle Objectives Milestone Review and the Lifecycle Architecture Milestone Review, respectively. It is not so obvious for the SSR and CDR. However, observing that almost all projects will have at least two iterations in elaboration and at least two in construction, it is recommended that SSR be combined with the Iteration Acceptance Review for the first iteration in the elaboration phase, and CDR be combined with the Iteration Acceptance Review for the first iteration in construction. In both cases, there is then good visibility of mature artifacts, with enough time remaining for correction - although the iterative approach should cope with this as a matter of course.
Just as the software process is influenced by the project's characteristics, so is the project organization. The default structure presented here (see the figure below), has to be adapted to reflect the effects of factors such as the ones listed:
These factors are discussed at length in Guidelines: Process Discriminants, here we will examine their effect on the choice of project structure. The figure below presents a default project organization, showing how responsibilities are assigned to the team structure.
Figure showing Default Project Organization. Note that there is no significance in terms of seniority or authority in the ordering of the roles.
This figure is a starting point for considering how project-level roles and responsibilities should be mapped to a structure of teams. The figure also serves to emphasize that roles (shown in the yellow boxes) are not individuals, but "hats" an individual (or a team) can wear in the project. It is for this reason that some roles (the Project Manager, for example) appear more than once. This indicates that, at some time, the behavior of the Project Manager, as defined in the RUP, may appear in more than one team. For example, in a large project, the task of preparing a status report based on a Work Breakdown Structure may be delegated to an individual in the Administration Team. However, this is a responsibility that the RUP assigns to the role called Project Manager.
In a small project, it is likely that an individual nominated as Project Manager will perform all the activities of the role called Project Manager, in which case the Administration Team coalesces with the Software Management Team. The selection of team structure will be influenced by the nature and size of the project but should be tempered by some, largely common-sense, rules:
The rationale for the default organization is discussed at length in [ROY98]. In particular, the assignment of responsibilities for deployment to the software assessment team recognizes that, of all the teams in a development project, the software assessment team has greatest exposure to the software as the end user will see it.
During the life of a project, the organization will evolve to support the work breakdown structure captured in the project plan. This is shown in the figure below, which is taken from [ROY98].
This evolution emphasizes a different set of activities in each phase:
Migration between teams during this evolution will ensure that knowledge and
capability is retained in the project. For example, when elaboration is
complete, some architecture team members could be dispersed into the development
teams, perhaps to act as team leads, or carry the architectural 'vision' into
development. Later still, towards the end of the construction phase, the focus
shifts to the assessment team, and there is a movement of staff from the
development team into the assessment team. It is also important at that stage,
to avoid the loss of architectural integrity in the heat of construction, that
the influence of the architecture team is not allowed to wane as the 'center of
gravity' of the project moves. Moving some architecture team members to the
assessment team is one way to do this.
Rational Unified Process