Effective Engineering e-Newsletter – 5/27/2004
This is your bi-weekly e-Newsletter from Effective Engineering Consulting
If you would like to receive Effective Engineering e-newsletters as
they are published, please send an email to firstname.lastname@example.org,
and we will add you to our distribution list.
Comments and suggestions are welcome and encouraged!
Development Methodology: Build –- to
Tom Dennis – President, Effective Engineering [email@example.com]
In two previous
e-Newsletters, I described the basics of development methodologies (see eN-030828
– Development Methodology Basics: Stages of Development, and eN-030911
– Development Methodology Basics: Management of Development).
Those e-Newsletters were able to cover only very broadly the basic
elements of development methodologies. The
Development e-Newsletter described Requirements, Architecture,
& Planning (see also eN-030925
– Development Methodology: Requirements, eN-031009
– Development Methodology: Architecture, and eN-031023
– Development Methodology: Failing to Plan Means You Are Planning to Fail!),
and briefly described Build & Test, and Release & Support as
two other stages of development. This
and some subsequent e-Newsletters will cover in somewhat more depth Build,
Test, Release, and Support.
Before the Build stage begins, it is critical that at least some
degree of Requirements, Architecture, & Planning has occurred, so
that the development engineers have a good idea of what to build.
If not, this stage can become bedlam, with everyone trying to both
define and execute simultaneously. This
is generally a blueprint for failure.
The Build stage is where the Requirements, Architecture,
and Planning are actually implemented.
This includes detailed software, firmware, hardware, and mechanical
design efforts per the design specifications that resulted from the previous
stages. It also includes
verification of the implemented design at the unit or module test level prior
to being handed off to Test.
There are many development methodology approaches that can be followed in
entering the Build stage. There
is the standard Waterfall development approach, where Requirements,
Architecture, and Planning are all completed and well documented
before the Build process begins, and where changes along the way are
actively discouraged. There are
also a variety of Iterative development approaches, where
initial Requirements, Architecture, and Planning are
prepared, Build efforts are initiated, and then Requirements, Architecture,
and Planning are iterated on as necessary changes are identified and
incorporated. Such iterations may
go on throughout the product development process.
The Waterfall approach applies best to very well understood
development projects where requirements and architecture can be completely
understood before implementation begins, and where the project can be planned
thoroughly well in advance, and where few, if any, surprises are expected
along the way. If anyone out
there knows of a product development project that satisfies the above
criteria, I’d really like to know. Most
development projects I’ve ever been involved with are far more chaotic, with
requirements changing frequently as new customer information, and therefore
requirements, are identified. Regardless
of this reality, many development projects are planned and attempted to be
carried out based on this approach.
The Iterative approach recognizes that many development projects
operate in the equivalent of a battle zone, where requirements frequently
change and must be responded to, where resources must be applied to adapt to
changes, where repeatable processes aren’t always effective, and where plans
must change. Battlefields are
messy, turbulent, uncertain, and full of change.
Newer methodologies, such as Agile Development 
approaches have been developed to help with such conditions. They recognize that unpredictability and turbulence define
the environment, and depend on “collaborative” values and principles, and
a “barely sufficient” methodology. There
are many Agile Development methodology variations.
Most development projects lie somewhere in between well defined and chaotic,
but they’re generally closer to chaos than to order.
Engineering organizations need to determine for themselves what type of
development approach works best for them.
Regardless of the approach, engineers involved in the Build stage need
to take the Requirements, Architecture, and Planning they
are given and start to reduce them to practice.
This means they must start to write the software or firmware code (C++,
Java, J2EE, XML, etc.) to implement the requirements that apply to them, or to
start designing the hardware (digital, analog, RF, ASIC, etc.) to implement
the requirements that apply to them, or to start designing the packaging
(including power, heat flow, plastics, etc.) to implement the requirements
that apply to them. These
implementations may go through few or many iterations depending on the
approach being followed and the individual circumstances encountered.
As portions of their design implementations get finalized, it is up to those
engineers to hold design reviews for their implementations.
As part of the design review, individual modules must be tested and
verified to be functional and error proof, and common combinations of modules
must be integrated and tested together to verify proper operation of the
intended functionality. This is
the responsibility of the developer, before handing off their piece of the
design to a test group. These
design reviews can be formal reviews with extensive documentation and formal
sign-off before acceptance of the design, or they may be informal “buddy
reviews”, where someone familiar with the functionality to be implemented
reviews and OK’s the design to move to the next stage.
It is up to the organization to determine how they want this done, but responsibility
and accountability for the developers and the reviewers is required if a
quality result is to be achieved.
The Build stage is where the rubber begins to meet the road; where
requirements on paper start to become real products.
If the proper groundwork has been laid, and if effective design
approaches are followed, this can be a controlled stage that smoothly
implements the desired outcome. If
done correctly, the build can be for a design that lasts, and one where
quality is designed in from the outset
Highsmith, “Agile Software Development Ecosystems”, Addison Wesley
Effective Engineering Consulting Services, All Rights Reserved