Building Quality in Designs for Better Products

By Peter Varhol

I just returned from the Conference of the Association for Software Testing, and have been giving some thought to how quality concepts apply to engineering designs. Is there a correlation between testing software applications and testing designs? I believe there is. The relationship is not in what we are testing, but in how we test.

  Today, you probably test your designs in a variety of ways. Simulation is one popular technique; if you can simulate motion, stresses, wear and tear, tolerances, and other aspects of physics on your design and how it might behave as a completed and manufactured product, you can make some important statements about its efficacy before you release the design to manufacturing.

  You can also test the design via prototyping, building a physical model to examine and test. A prototype can be simple or complex, from a clay mockup to an early but fully functional implementation of the final product. Of course, there is a law of diminishing returns involved; the more time you put into building a more complex prototype, the less time you have to test it.

  All these types of tests are good for ensuring quality. But they have limitations. Perhaps the most significant limitation is that even if the design is tested for fitness of purpose at the end of the process, it is too late to make substantive changes to the design while still meeting time-to-market requirements.

  Much of today’s emphasis in software development is in iterative design, build, and test—termed an agile approach in software parlance. Traditional software development methods typically have prospective users or user representatives defining business requirements for the product,  which are then translated into functions, specifications, and finally working code.

  An agile approach, on the other hand, involves just enough understanding of the problem domain and designing the application to start coding software. User stories rather than business requirements describe how it will be used, and development occurs a few features at a time, and very quickly, in the span of weeks or even days. Those features are shown to representative end users who provide fast feedback. The development team adjusts and goes through the same fast iteration again until a usable software application emerges.

  Is there an equivalent approach in design engineering? I don’t think so. The auto industry has been trying for years, with mixed success, to shorten its product-design cycles. However, the amount of time a new model spends in conceptualization and design is still measured in years.

  For other, simpler products, an agile design strategy may seem redundant, as many designs take months or even weeks anyway. And a tangible product isn’t like software, you may argue. They are not possible to test until the design is complete.

  I disagree. I think engineers can and should do iterative designs, and there should be extensive involvement from users during that design process. It may involve different design possibilities, or it might mean engineers start with the aggregate and design in sets of details in stages. At each stage, the design is prototyped, and users are invited to preview the implemented features.

  If it sounds too pat, it probably is. This kind of shift in philosophy is unlikely to speed up the design process, at least initially. But we’ll likely end up with a better model of user expectations.

Contributing Editor Peter Varhol has been involved with software development and systems management for many years. Send comments about this column to [email protected].