Top 10 modeling hints for system engineers: #2 It is better to avoid defects than to fix them

Bruce Douglass brings us the next installment in his Top 10 modeling hints for system engineers series where he shares why avoiding defects is better than fixing them.


Bruce Douglass (, Rational Chief Evangelist, Systems Engineering, IBM

author photoEmbedded Software Methodologist. Triathlete. Systems engineer. Contributor to UML and SysML specifications. Writer. Black Belt. Neuroscientist. Classical guitarist. High school dropout. Bruce Powel Douglass, who has a doctorate in neurocybernetics from the USD Medical School, has over 35 years of experience developing safety-critical real-time applications in a variety of hard real-time environments. He is the author of more than 5,700 book pages from a number of technical books including Real-Time UML, Real-Time UML Workshop for Embedded Systems, Real-Time Design Patterns, Doing Hard Time, Real-Time Agility, and Design Patterns for Embedded Systems in C. He is the Chief Evangelist at IBM Rational, where he is a thought leader in the systems space. Bruce consults with and mentors IBM customers all over the world. Follow Bruce on Twitter @BruceDouglass.

17 December 2013

Also available in Chinese Russian Japanese

A tradition waterfall, or V-cycle, development project proceeds stage by stage through a series of activities with this fundamental assumption: the work in each stage can be completed with no more than a few minor defects. This is the theory, at least.

Figure 1. Typical V-cycle process
v cycle diagram

Click to see larger image

Figure 1. Typical V-cycle process

v cycle diagram

However, based on project evidence, this is simply not true. If it were true, system V&V tests would pass the very first time, most of the time. Only occasionally would the system require any defect removals. And, very rarely would this require any serious work or cost overruns. That is not what we see with over 1/3 of projects being over cost and over time. A significant number of projects are so over budget that they are cancelled prior to completion.

Verification-at-the-end identifies problem defects at the end of the project. At the end of the project is when you expect to be finished. The cost is high for two reasons. Partly to identify and isolate the defect in the fully constructed system, but mostly to the large cost of throwing away significant portions of work products (requirements, architecture, design, code, test cases, etc) and redeveloping them. The cost of rework is the real killer of projects.

I believe that it is better to avoid defects in the first place rather than insert them early and fix them late. The question of how to avoid defects is the real issue. There are a number of practices that help you to do that:

  • Test-driven development with high-fidelity modeling (TDD-HFM)
  • Continuous integration
  • Incremental V&V
  • Continuous QA
  • Continuous dependability assessment

Of these, I'll focus on TDD-HFM. All are important and remove defects before they become embedded in the system design. But I've found TDD-HFM of particular value. Test-driven development was developed in the context of agile software development as a means to avoid defects. The idea is to develop, and apply, test cases at the same time as you develop source code. This happens in very small cycles (which Harmony calls nanocycles) of 20-60 minutes. The goal is to never go more than this short period of time before you verify that what you have created (so far) is actually correct. This means that you take verification from the end of the process and make it a part of your normal hourly workflow.

Testing only at the end makes no more sense than only brushing your teeth on December 31 because "it's that time of the year." You can avoid dental problems with the application of continuous (or at least daily) hygiene. TDD is no more or less than hygiene for your system engineering work products. Hygiene is defined by Merriam Webster as "conditions or practices conducive to maintaining health and preventing disease, esp. through cleanliness." I think this definition is particularly appropriate to the development of engineering work product.

As systems engineer you must make work products that lend themselves to verification. See Tip #7 Requirements models avoid expensive defects for more information on this topic. This applies to most system engineering work products. If you want to have a good (complete, consistent, accurate and correct) set of requirements, build a verifiable requirements model. If you want to construct a good (optimal) architecture, build a verifiable architecture model.

While a big part of the answer, by itself it is insufficient. It is not enough to be verifiable; it must also be verified. The best way to construct a verified work product is to verify it continuously as it is developed. This test-driven development approach removes the vast majority of defects that otherwise remain dormant. They usually show up as a surprise to the development or testing team, or – in the worst case – the customer.

Consider the problem of constructing a defect free set of requirements. The workflow in Figure 2 shows how this can be done. The key to effectively executing this workflow is to keep the cycles short and focused.A cycle usually ranges from 20 minutes to an hour. For the inner requirements modeling loop this means that a small set of requirements from the use case:

  • Update the execution context
  • Manifest the requirements in the scenarios and functional flow
  • Incrementally update the state machine
  • Verify this update

If you have questions to ask the customer, or features you wish to demonstrate, you can expose the model (as a simulation) to the customer for evaluation and consideration.

Figure 2: Test-driven development-high-fidelity modeling workflow for requirements analysis
modeling workflow

Click to see larger image

Figure 2: Test-driven development-high-fidelity modeling workflow for requirements analysis

modeling workflow

This leads us to the #1 hint for developing systems, stay tuned.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Top 10 modeling hints for system engineers: #2 It is better to avoid defects than to fix them