Over the past decade, advancements in static analysis tools from both commercial and open source communities have dramatically improved the detection of developer violations of good coding practices. The ability to detect these issues in coding practices provides the promise of better software quality.
Yet many of these static analysis tools cannot detect the critical violations that exist in multilayer architectures, across transactions and multi-technology systems. These are the violations that lead to 90% of a systems reliability, security and efficiency issues in production.
Ovum Analyst Chandranshu Singh points out, “Holistic system approach, looking at the architecture, transactions, control, and data flow across multiple technologies, may be very beneficial, with numerous engineering studies showing that bad software engineering practices in the ways components are interrelated and interact…account for only 10% of total defects, but can lead to 90% of production issues.”
Code Checking is not enough
Structural quality weaknesses – such as those enumerated in the table below aligned with the characteristics they may affect – can manifest themselves in many different ways across languages and technologies…and some weaknesses may not be relevant to some languages. Large, modern business applications are architected in multiple layers, each of which may be developed in a different language or technology. Consequently, the analysis of software quality at the system level is challenging. It requires parsing several languages and rebuilding an abstract representation of the application system, from which patterns and other markers of structural weakness can be detected.
The problem with traditional testing approaches and tools is that even though software quality characteristics generally describe external behavior, the internal weaknesses in the system are most often the root cause of undesirable behaviors: performance, reliability and security issues.
A software quality standard for IT business applications published by the Consortium for IT Software Quality (CISQ), a consortium co‐sponsored by the Object Management Group and the Software Engineering Institute at Carnegie Mellon University, defines the underlying rules of good architectural and coding practice that must be checked.
They classify software engineering best practices in two categories:
1. Rules of good coding practice within a program at the Unit Level without context in which the program operates
2. 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.
(Figure 1 illustrates these rules at the Unit and Technology/System Levels.)
To learn more about CISQ Software Quality standards and how to supplement your testing and development processes with Architectural and Structural Quality Analysis, view this video: https://www.youtube.com/watch?v=XRieu1Z6uXw