Share this:

The Relationship Between Unit and System Level Issues

Bill Dickenson, Independent Consultant, Strategy On The Web


Dr. Richard Soley, the Chariman and CEO of OMG, published a paper for CISQ titled, How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations, that outlines the software quality standard for IT business applications. He classified software engineering best practices into two main categories:

  • Rules of good coding practice within a program at the Unit Level without the full Technology or System Level context in which the program operates, and
  • Rules of good architectural and design practice at the Technology or System level that take into consideration the broader architectural context within which a unit of code is integrated.

Correlations between programming defects and production defects revealed something really interesting and to some extent, counter-intuitive. It appears that basic Unit Level errors account for 92% of the total errors in the source code. That’s a staggering number. It implies that in fact the coding at the individual program level is much weaker than expected even with quality checks built into the IDE. However, these code level issues eventually count for only 10% of the defects in production. There is no question that it drives up the cost of support and maintenance as well as decreased flexibility, but the translation of these into production defects is not as large as might be expected. It also calls into question the effectiveness of development level IDE to eliminate production defects.


On the other hand, bad software engineering practices at the Technology and System Levels account for only 8% of total defects, but consume over half the effort spent on fixing problems. This eventually leads to 90% of the serious reliability, security, and efficiency issues in production. This means that tracking and fixing bad programming practices at the Unit Level alone may not translate into the anticipated business impact, since many of the most devastating defects can only be detected at the Technology and System Levels.


When we review the information from the CRASH database, this is not wholly unexpected. Many of the more serious defects are undetected until the components interact.

One thought on “The Relationship Between Unit and System Level Issues

  1. Pingback: How to Identify Architecturally Complex Violations | CISQ - Consortium for IT Software Quality

Leave a Reply

Your email address will not be published. Required fields are marked *



Comment validation by @