Effective Engineering e-Newsletter – 8/28/2003
This is your bi-weekly e-Newsletter from Effective Engineering Consulting
Services (www.effectiveeng.com).
If you would like to receive Effective Engineering e-newsletters as
they are published, please send an email to e-newsletter@effectiveeng.com,
and we will add you to our distribution list.
eN-030828:
Development Methodology Basics: Stages of Development
By
Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]
Too many engineers believe product development begins
when they start their detailed design or coding, and ends when product is
released to manufacture. This
couldn’t be more wrong, and products developed under such an approach are
usually destined to fail badly. A
framework for proper product development, also known as a development
methodology, is required. Such a
methodology covers the appropriate stages and management of development,
including what needs to be done, why, by whom, when, and how.
The subject of development methodology is broad, and can be very
complex. In the next two
e-Newsletters, I will simply attempt to cover, very briefly, what many
of the major elements of a development methodology are.
In subsequent e-Newsletters, I will go into more detail about many of
the specific elements that are only briefly touched on here.
The level of development methodology also varies broadly (see eN-030731
– Development Methodology: Too Little, Too Much, or “Just Right”?).
Most broadly, a development methodology covers the Stages of Development,
and the Management of Development.
This e-Newsletter will cover the Stages of Development (Requirements
& Architecture, Build & Test, and Release &
Support), and the next e-Newsletter will cover the Management of
Development (see eN-030911 – Development
Methodology Basics: Management of Development).
Stages of Development:
► Requirements & Architecture:
This stage is the most critical, and often the stage that is given far less
attention than it deserves. This stage forms the foundation that the product and project
is based upon. If the foundation
is weak, then the construction built upon that foundation is likely to
collapse and fail. People are
often in a rush to start building something, even if they’re not sure what
exactly to build. Do so, and you
will pay the consequences later. Time
spent in the Requirements & Architecture stage is time well spent and can
significantly reduce the time spent in the Build & Test
stage, and significantly improve the overall product quality.
Typically, one third to one half of the overall development interval
should be spent in the Requirement & Architecture stage.
● Requirements includes everything needed to properly
define the WHAT, WHO, and WHEN of the product to be built.
WHAT includes specifically what the product is to be and what it
is not to be (see eN-030619 – What Do Your
Customers Really Want?). WHAT also includes the overall functional specs,
architecture specs, detailed design and test specs, project plans, customer
support documents, etc. WHO
includes the specific allocation of resources for the various tasks to be
undertaken, to prepare the various requirements documents (broad, technical,
and detailed), to develop the project plans, to define the architecture(s) to
be used, to design, test, and document the product, to manage the project, to
support the product, etc. WHEN
includes detailed milestones, schedules, dependencies, resource allocation
timeframes, and any other time-related activities associated with product
development.
● Architecture includes everything needed to properly
define the WHY and HOW about the product to be built.
WHY includes understanding the most critical aspects for the
product’s success (e.g. speed, latency, transaction handling, accuracy,
etc.), and then determining the best architectural approaches to achieve that
success. HOW includes
examining alternate architectures to see what works best.
By doing proper performance engineering during this stage, at the
concept level, proper architectural choices can be made early, rather than
discovering much later, when corrective actions may be extremely difficult,
that bad architectural choices were made.
► Build & Test:
This stage is the carrying out of all of the decisions and
requirements, and building of the architecture(s), as specified during the Requirements
& Architecture stage. If
the Requirements & Architecture stage has been properly
completed, this should be a fairly straightforward process.
If not, then this stage can become bedlam, with everyone trying to both
define and execute simultaneously. This
is generally a blueprint for failure.
● Build includes detailed hardware, firmware, software,
and mechanical design per the design specifications.
It also includes verification of the design at the unit or module
level, before the unit or module is formally turned over to the test group.
● Test includes all elements of testing, including module
test, integration test, functional test, system-level test, “white-box”
test, “black-box” test, negative test, regression test, testing “outside
the box”, and more. The intent of test efforts is to find any problems customers
may uncover before the product ever reaches a customer.
► Release & Support:
This is the stage where the product is released to be manufactured, and
then encounters real customers.
● Release includes everything needed to formally turn the
product design information over to manufacturing.
This includes documentation (drawings, files, software, tests, etc.),
and any other information that manufacturing may need to properly build and
ship the product (e.g. packaging, labeling, pricing, etc.).
● Support includes everything needed to properly support
the product once it has reached customers, be they end users, distributors, or
anyone else. This includes
documentation, training, update processes, and anything else intermediate or
end user customers may require.
This has been a very brief summary of the major stages of development. How these stages, and the elements within, are managed will
be discussed in the next e-Newsletter. More
details about many of these elements are needed, and such details will be
topics of many subsequent e-Newsletters.
Copyright ©
2003
Effective Engineering Consulting Services, All Rights Reserved
