Code Quality Standards

IT organizations can use code quality standards to detect and quantify critical violations of good coding and architectural practice in software. Measure software against standards at every release, e.g., measure code compliance to secure architectures, and put CISQ software quality measures into contracts with outside developers or software vendors to track to established outcomes.


Published Standards Available for Use

Automated Quality Characteristic Measures in Detail


The nonfunctional requirements of software can be traced to the most damaging of system failures and security breaches and are at the core of CISQ’s code quality standards and recommendations. The measures are designed to be automated on source code to identify critical vulnerabilities in the software that are severe enough that they need to be fixed. Combined with a sizing measure, a density metric is produced for each quality characteristic. Thresholds can be set for each characteristic.


The CISQ Quality Characteristic Measures cover eighty-six well-established software engineering rules to ensure secure, reliable, efficient and easy to maintain software. The measures are consistent with ISO/IEC 25010 definition. The following table shows a snapshot of software engineering rules contained in the measurement of each quality characteristic at the unit level and system level.



Software Quality Characteristic Good Coding Practices
Unit Level
Good Architectural Practices
System Level
  • Protecting state in multi-threaded environments
  • Safe use of inheritance and polymorphism
  • Resource bounds management, Complex code
  • Managing allocated resources, Timeouts
  • Multi-layer design compliance
  • Software manages data integrity and consistency
  • Exception handling through transactions
  • Class architecture compliance
  • Compliance with Object-Oriented best practices
  • Compliance with SQL best practices
  • Expensive computations in loops
  • Static connections versus connection pools
  • Compliance with garbage collection best practices
  • Appropriate interactions with expensive or remote resources
  • Data access performance and data management
  • Memory, network and disk space management
  • Centralized handling of client requests
  • Use of middle tier components vs. procedures/DB functions
  • Use of hard-coded credentials
  • Buffer overflows
  • Missing initialization
  • Improper validation of array index
  • Improper locking
  • Uncontrolled format string
  • Input validation
  • SQL injection
  • Cross-site scripting
  • Failure to use vetted libraries or frameworks
  • Secure architecture design compliance
  • Unstructured and duplicated code
  • High cyclomatic complexity
  • Controlled level of dynamic coding
  • Over-parameterization of methods
  • Hard coding of literals
  • Excessive component size
  • Duplicated business logic
  • Compliance with initial architecture design
  • Strict hierarchy of calling between architectural layers
  • Excessive horizontal layers
  • Excessive multi-tier fan-in/fan-out


CISQ working groups are led by Dr. Bill Curtis, Executive Director of CISQ, and author of the Capability Maturity Model. Read Dr. Bill Curtis’ biography.


For guidance on applying software quality metrics, read these whitepapers:


In this video Dr. Bill Curtis discusses software quality standards: