You
may also choose a combination of both.
Let us assume for the moment
that what we are building is an enhancement release, version 2.0, of an
existing product. If the focus of the enhancement is on providing new features
and functions, it is natural to decompose the construction phase along
the functional requirements. If the focus is on a new hardware/software
platform and involves architectural changes, decomposition along the software
components is natural.
So far, I have discussed
the case of developing an enhancement release of an existing system. Preparing
a WBS for creating the first generation system is not quite as clear-cut.
The major difference is that there are many more unknowns. The system is
not constrained by an existing architecture or existing features and functions.
For a first-generation
system, the detail will be developed over time. Each phase or iteration
within the phase is a “mini” project. Each iteration goes through all the
aspects of software development, that is, through all process components,
although the emphasis is different for each component. The work that is
accomplished has two purposes: not only making progress toward creating
the final product, but also gaining more information in the areas that
are less understood.
The number of iterations
in each phase depends on the size and complexity of the project. How well
the problem is understood also influences the number of iterations. For
example, if a function has never been automated before, the first iteration
of the elaboration phase may define the scope of the functionality and
select the hardware/software. The second iteration may involve the development
of a functional prototype and the definition of the non-functional requirements.
In general, more iterations
buy more decision points for making a Go or No-Go decision and allow for
more corrections of the strategy. The following considerations help decide
on the number of iterations for the construction phase:
-
The effort involved in testing
and planning for the transition between iterations. The more iterations,
the more time and effort will be spent in transitioning between iterations.
With more iterations, make sure that these transition tasks, such as testing,
are as automated as possible and overlap with planning for the next iteration.
-
The increase of control
through additional decision points. More iterations provide you with
more opportunities for adjusting and fine-tuning your goals.
-
The duration of the iterations.
As a rule of thumb, the duration of an iteration is between three and six
months.
-
The demand for early delivery.
If early feedback is needed from the market place, or market presence is
critical, then the first iteration may be shortened with a focus on the
core functions of the product. The first iteration is followed by a sequence
of enhancement iterations.
|
To conclude this discussion,
I want to repeat that the software development process is a thinking tool
for selecting a strategy for developing your software system. The WBS
is a pyramid of objectives. It shows the interdependencies between
the business objectives, the strategy for developing the software system,
and the engineering work for creating it.
Omni-Vista
SP - A New Tool for Balancing Project Schedule, Scope and Cost
The challenge: Marketing mandates a product release
date of 4/1/00. Finance expects to break even within the first two years
of product release. The engineering manager claims that the earliest
product release date is 6/1/00, even after adding two more developers.
Sounds familiar? The questions are - What is a realistic product scope
and release date? and How can we come to an agreement?
Omni-Vista SP is a decision support tool that
helps software development organizations make trade-off decisions between
features and functions of the product, release date, and expected revenue.
The tool is designed for use during the inception and elaboration phase
of a software project (see Figure 2). With Omni-Vista SP development management
can make informed decisions based on schedule probability, budget probability,
budget, and technical and schedule risk. Marketing and finance can analyze
the project based on market segments and their penetration, expected product
revenue and the break-even point.
To enable these functions, Omni-Vista SP maintains
constraint equations with development, marketing and financial parameters
and visualizes the results using line graphs, histograms and Gantt charts
(see Figure 4).
Figure 4: Break-even, Schedule Probability and Project Risk
I had the opportunity to test-drive Omni-Vista SP
using data from a past project with six months duration and 92 product-level
requirements. I found the tool easy to use and the graphs intuitive.
Omni-Vista SP can import requirements and resources
from comma-separated ASCII files; however, the import functions require
performance improvement.
Omni-Vista SP provides a place for engineering
and marketing to come to an agreement on the product scope and release
date. It is valuable for making an informed Go/No-Go project decision.
Omni-Vista SP also makes it possible to learn from the past by analyzing
the parameters from completed projects.
For more information, visit http://www.omni-vista.com.
|