Software Development Plan
Software Development Plan
|A time-sequenced set of
activities and tasks, with assigned resources, containing task dependencies,
for the project.
Determining the Length of each Iteration
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.
- Five people can do some planning on a Monday morning, have lunch together
every day to monitor progress, reallocate tasks, start doing a build on
Thursday, and complete the iteration by Friday evening.
- But this will be very hard to achieve with 20 people. It will take more
time to distribute the work, synchronize between subgroups, integrate, and so on.
An iteration may take rather three or four weeks.
- With 40 people, it already takes a week for the "nervous influx to go
from the brain to the extremities". You have intermediate levels of
management, the common understanding of the objective will require more
formal documentation, more ceremony. Three month is a more likely reasonable
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::
of an Iteration
- Iterations of more than 6 months probably need to have
intermediate milestones built in to keep the project on track. Consider
reducing the scope of the iteration to reduce its length and ensure a clear
- Iterations of more than 12 months create their own risk,
as the iteration spans the annual funding cycle. A project which has not
produced anything visible in the past 12 months is at risk of losing its
- Iterations of less than 1 month need to be scoped
carefully. Typically, short iterations are more suitable for the
Construction phase, where the degree of new functionality to be included and
the degree of novelty are low. Short iterations may do little or no formal
analysis or design, and may simply be incrementally improving
- Iterations need not all be the same length: their length
will vary according to their objectives. Typically, elaboration iterations
will be longer than construction iterations. Within a phase, iterations are
generally the same length (it makes planning easier).
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.
Example Iterations for a
Private Telephone Switch
- Iteration 1: local call.
- Iteration 2: add external calls and subscriber management.
- Iteration 3: add voice mail and conference calls.
Determining the Number of Iterations
A very simple project may have only one iteration per phase:
- One iteration in the inception phase, producing perhaps a proof-of-concept
prototype, or user-interface mock-up, or no iteration at all, in the case
for example of an evolution cycle.
- One iteration in the elaboration phase to produce an architectural
- One iteration in the construction phase to build the product (up to a
- One iteration in transition to finish the product (full product release).
For a more substantial project, in its initial development cycle the norm
- One iteration in the inception phase (possibly producing a prototype).
- Two iterations in the elaboration phase; one for an architectural
prototype, and one for the architectural baseline.
- Two iterations in the construction phase to expose a partial system, and
- One iteration in the transition phase to go from initial operational
capability to full product release.
For a large project, with lots of unknowns, new technologies, and the like,
there may be a case for:
- an additional iteration in the inception phase, to allow for more
- an additional iteration in the elaboration phase, to allow different
technologies to be explored.
- an additional iteration in the construction phase because of the sheer
size of the product.
- an additional iteration in the transition phase to allow for operational
So over a development cycle, we have:
- Low: 3 iterations [0,1,1,1]
- Typical: 6 [1, 2, 2, 1]
- High: 9 [1, 3, 3, 2]
- Very High: 10 [2, 3, 3, 2]
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:
- If the product is intended for some totally new domain,
you may need to add some iterations in the inception phase to consolidate
the concepts, show various mock-ups to a cross-section of customers or end
users, or build a solid response to a request for proposal.
- If a new architecture must be developed, or there is a
large amount of use-case modeling, or there are very challenging risks, you
should plan to have two or three iterations in the elaboration phase.
- If the product is large and complex, and developed over a
long period, you should plan to have three or more iterations in the
- You should plan to have several iterations in the transition phase if,
because you must minimize the time to market, you must deliver the product
with a reduced set of functionality, or if you feel you may need a lot of
small adaptations to the end-user base after a period of use.
Aligning the Traditional Waterfall Review Sequence with the Iterative Approach
The default review sequence for a waterfall life-cycle project has a single
major review at the completion of the important artifacts, for example:
- System Requirements Review (SRR), at the completion of
the system specification;
- Software Specification Review (SSR), at the completion of
the software requirements specification;
- Preliminary Design Review (PDR), at the completion of the
architectural design sections of the software design description;
- Critical Design Review (CDR), at the completion of the
detailed design sections of the software design description.
In the Unified Process for EDUcation (UPEDU), 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 UPEDU 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 UPEDU, to locate the points at
which these important artifacts (actually, their equivalents in the UPEDU) 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 UPEDU as in the (ideal) waterfall life cycle - but that the effort
will be distributed differently. The result is the following:
- the SRR (concerned mainly with the Vision)
can be scheduled at the end of the inception phase;
- the SSR (concerned mainly with the Software
Requirements Specification) at about 1/3 of the way through the
- the PDR (concerned mainly with the Software
Architecture Document) at the end of the elaboration phase;
- the CDR (concerned mainly with the Design
Model) at about 1/3 of the way through the construction phase.
For efficiency, the Project Manager, in consultation with the customer,
should attempt to combine these reviews with the prescribed UPEDU 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.
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
- The Business Context
- The Size of the Software Development Effort
- The Degree of Novelty
- Type of Application
- The Current Development Process
- Organizational Factors
- Technical and Managerial Complexity
The figure below presents a default project organization,
showing how responsibilities are assigned to the team structure.
Figure showing UPEDU's Project Organization. Note that
there is no significance in terms of seniority or authority in the ordering of
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 UPEDU, 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 UPEDU 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
- small teams are usually more productive; however, in a large project this
has to be balanced against the amount of cross-team interaction;
- deep hierarchies are to be avoided;
- the span of control of any manager or team lead should be limited to seven
plus or minus two;
- the software development team structure
should be driven by the software architecture (not vice
versa); a good architecture, with high cohesion and low coupling between
subsystems, will allow teams to work more effectively in parallel;
- testing, other than unit test, should ideally be performed by a team
separate from the development team. Note, however, that this may not make
economic sense in a very small project;
- the structure must allow all teams and individuals to be given clearly
defined authorities and responsibilities. This is particularly important if
the hierarchy exceeds three levels. The managers and team leads in the
middle of such structures need to understand what is required of them in
balancing technical and managerial activities.
- the structure must support the capabilities, experience and motivations of
the staff: for example, if a single team is supposed to perform analysis,
design and implementation, without any intermediate hand-off, it will need
all the necessary competencies. Skilled analysts are not necessarily good
- team structures should not be rigid: individuals will migrate between
teams over the project's lifetime, and the responsibilities of teams will
change as the emphasis of the project shifts from phase to phase.
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:
- the Inception team: an organization focused on planning, with enough
support from the other teams to ensure that the plans represent a consensus
of all perspectives;
- the Elaboration team: an architecture-focused organization in which the
driving forces of the project reside in the software architecture team and
are supported by the software development and software assessment teams as
necessary to achieve a stable architecture baseline;
- the Construction team: a balanced organization in which most of the
activity resides in the software development and software assessment teams;
- the Transition team: a customer-focused organization in which usage
feedback drives the deployment activities.
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.