Effective Engineering 
                Consulting Services
   
                                           "Helping Engineering Excel!"

Home
Our Premise
The Problem
Our Promise
Our Approach
Our Deliverables
Case Study
Our Results
e-Newsletters
Our People
Contact Us
Photos

 

Back to e-Newsletter Archives:

 Effective Engineering e-Newsletter – 5/27/2004

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.  Comments and suggestions are welcome and encouraged!


eN-040527:

Development Methodology: Build –- to Last
  By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.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 Stages of 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 [1] 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

_______________________________________
[1]
Jim Highsmith, “Agile Software Development Ecosystems”, Addison Wesley 2002


Copyright © 2004 Effective Engineering Consulting Services, All Rights Reserved

Back to e-Newsletter Archives:

 

   

Society of Professional Consultants

  

Copyright © 2002-2013 Effective Engineering Consulting Services, All Rights Reserved