November 29, 2020
Hot Topics:

Software Quality Metrics

  • By Bijay Jayaswal & Peter Patton
  • Send Email »
  • More Articles »

Pattern Metrics in OOAD

Object-Oriented Analysis and Design (OOAD) has at last come of age; it is the preferred software development technology today. Sophisticated online transaction-oriented applications and systems in aerospace and medical technology have been using C++ for years. The emergence of Java as the preferred language for Internet application development has established OOAD and Object-Oriented Programming (OOP) as major players. Many college and university computer science programs are Java-based nowadays, and many application groups are busy converting COBOL and PL/1 applications to Java. The use of OOAD both in the development of new systems and in their conversion from legacy procedural language implementations favors the discovery and use of design patterns. A design pattern is a microarchitecture that provides a proven solution to design problems that tend to recur within a given application or software development context. A design pattern includes its static structure as the hierarchy of classes and objects in the pattern and their relationships. It also includes the behaviors (to use the Java term) or dynamic relationships that govern how the objects exchange messages. Design patterns are classified by their users into three groups; they are either creational, structural, or behavioral. Creational patterns concern object creation. Structural patterns capture class or object composition. Behavioral patterns deal with how classes and objects interact. Most patterns are discovered in existing software packages when they are either modified or rewritten by very senior programmers or software architects who notice their repetitive occurrences. A research group at the Institute for Scientific and Technical Research in Trento, Italy has developed a set of metrics for OO software applications that allow them to extract design patterns automatically.21

Ostensibly the major benefit of understanding and using repeating design patterns in OOP is to enhance code reusability. However, software quality enhancement has significant benefits as well. Not only do patterns reduce the unique SLOC in an application, they also reduce its effective volume, increase development productivity, and simplify later enhancement and maintenance. The technology frontier in software development today is learning how to break high-level architectural design into its architectural components. This is similar to how a building architect breaks his or her overall design into horizontal microarchitectures such as stories and plazas and into vertical micro-architectures or infrastructure components such as HVAC, plumbing, power, elevators, and stairways.

The future of software quality is further automation by automatic program generation. This means the ability to break the overall customer-responsive architecture (form follows function) into successively lower levels of architecture, down to micro-architectures such as design patterns from which quality application software can be generated automatically.

Key Points

  • Historically software quality metrics have measured exactly the opposite of quality—that is, the number of defects or bugs per thousand lines of code.
  • Software is a multidimensional concept that can be viewed from many professional and user viewpoints.
  • Two leading firms in customer-focused software quality are IBM and Hewlett-Packard.
  • IBM has a proprietary measure set, whereas HP uses five Juran quality parameters.
  • The Naval Air Systems Command coined the term Total Quality Management (TQM) in 1985 to describe its own quality improvement program. It soon spread worldwide.
  • The four essential characteristics of a TQM program in any field are customer focus, process improvement, quality culture, and measurement and analysis.
  • TQM made an enormous contribution to the quality of enterprise software in the early 1990s, just in time for the Y2K transition.
  • Until recently, most software quality metrics were of an in-process nature; metrics to support DFTS must be applied upstream in the development process.
  • Small programs (less than 100 LOC) exhibit 1.5 defects per KLOC. Large programs (more than 1,000 LOC) exhibit 1.5 defects per KLOC. Medium-sized programs often have only 0.5 defects per KLOC.
  • Sophisticated software tools for measuring software quality, such as PAMPA, are beginning to appear.
  • OOP goals in software reusability tend to enhance software quality as well.

Additional Resources


  1. M. Shaw and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline (New Jersey: Prentice Hall, 1996), p. 1.
  2. P. B. Crosby, Quality Is Free: The Art of Making Quality Certain (New York: McGraw-Hill, 1979).
  3. J. M. Juran and F. M. Gryna, Jr., Quality Planning and Analysis: From Product Development Through Use (New York: McGraw-Hill, 1970).
  4. S. H. Kan, Metrics and Models in Software Quality Engineering (Singapore: Pearson Education, 2003), p. 7.
  5. P. C. Patton and L. May, "Making Connections: A five-year plan for information systems and computing," ISC, University of Pennsylvania, 1993.
  6. IEEE, Standard for a Software Quality Metrics Methodology (New York: IEEE, Inc., 1993).
  7. Ibid, p. 10.
  8. Op cit Kan, p. 312.
  9. Op cit Kan, p. 327.
  10. S. D. Conte, H. E. Dunsmore, V. Y. Shen, Software Engineering Metrics and Models (Menlo Park, CA: Benjamin/Cummings, 1986).
  11. IFPUG, International Function Point User's Group Standard (IFPUG, 1999).
  12. D. B. Simmons, N. C. Ellis, H. Fujihara, W. Kuo, Software Measurement: A Visualization Toolkit for Project Control and Process Measurement (New Jersey: Prentice-Hall, 1998).
  13. Op cit Kan, p. 55.
  14. Op cit Simmons, et al., p. 250.
  15. Ibid, p. 257.
  16. D. Garlan, R. Allen, J. Ockerbloom, "Architectural mismatch: why reuse is so hard," IEEE Software, Nov. 1995, pp. 17.26 (p. 20).
  17. D. Garlan and D. Perry, "Introduction to the special issue on software architecture," IEEE Transactions on Software Engineering, April 1995, pp. 269.274 (p. 269).
  18. Op cit Shaw and Garlan, p. 1.
  19. G. Avritzer and E. J. Weyuker, "Investigating Metrics for Architectural Assessment," Proceedings of the Fifth International Software Metrics Symposium, pp. 2.10.
  20. Ibid, p. 8.
  21. G. Antoniol, R. Fiutem, L. Cristoforetti, "Using Metrics to Identify Design Patterns in Object-Oriented Software," Proceedings of the Fifth International Software Metrics Symposium, pp. 23.34.

About the Authors

Bijay Jayaswal is the CEO of Agilenty Consulting Group, LLC. He has held senior executive positions and has consulted in quality and strategy for the last 20 years and has helped introduce corporate-wide initiatives in reengineering, Six Sigma, and Design for Six Sigma and has worked with senior executive teams for effective implementation of such initiatives.

Peter Patton has been a leader of large development projects and is the author of seventeen books, book chapters, and monographs on computer hardware and software architecture. Both authors have done extensive writing and college teaching, as well as consulting to software development groups.

About the Source of the Material

Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software
By Bijay Jayaswal, Peter Patton

Published: Aug 31, 2006, Hardcover: 840 pages
Copyright 2007 Pearson Education, Inc.
ISBN: 0131872508
Retail price: $64.99

Page 4 of 4

This article was originally published on November 17, 2006

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date