Software quality

In the context of software engineering, software quality refers to two related but distinct notions:[citation needed]

  • Software's functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications.[1] That attribute can also be described as the fitness for the purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product.[2] It is the degree to which the correct software was produced.
  • Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability. It has a lot more to do with the degree to which the software works as needed.

Many aspects of structural quality can be evaluated only statically through the analysis of the software's inner structure, its source code (see Software metrics),[3] at the unit level, and at the system level (sometimes referred to as end-to-end testing[4]), which is in effect how its architecture adheres to sound principles of software architecture outlined in a paper on the topic by Object Management Group (OMG).[5]

Some structural qualities, such as usability, can be assessed only dynamically (users or others acting on their behalf interact with the software or, at least, some prototype or partial implementation; even the interaction with a mock version made in cardboard represents a dynamic test because such version can be considered a prototype). Other aspects, such as reliability, might involve not only the software but also the underlying hardware, therefore, it can be assessed both statically and dynamically (stress test).[citation needed]

Using automated tests and fitness functions can help to maintain some of the quality related attributes. [6]

Functional quality is typically assessed dynamically but it is also possible to use static tests (such as software reviews).[citation needed]

Historically, the structure, classification, and terminology of attributes and metrics applicable to software quality management have been derived or extracted from the ISO 9126 and the subsequent ISO/IEC 25000 standard.[7] Based on these models (see Models), the Consortium for IT Software Quality (CISQ) has defined five major desirable structural characteristics needed for a piece of software to provide business value:[8] Reliability, Efficiency, Security, Maintainability, and (adequate) Size.[9][10][11]

Software quality measurement quantifies to what extent a software program or system rates along each of these five dimensions. An aggregated measure of software quality can be computed through a qualitative or a quantitative scoring scheme or a mix of both and then a weighting system reflecting the priorities. This view of software quality being positioned on a linear continuum is supplemented by the analysis of "critical programming errors" that under specific circumstances can lead to catastrophic outages or performance degradations that make a given system unsuitable for use regardless of rating based on aggregated measurements. Such programming errors found at the system level represent up to 90 percent of production issues, whilst at the unit-level, even if far more numerous, programming errors account for less than 10 percent of production issues (see also Ninety–ninety rule). As a consequence, code quality without the context of the whole system, as W. Edwards Deming described it, has limited value.[citation needed]

To view, explore, analyze, and communicate software quality measurements, concepts and techniques of information visualization provide visual, interactive means useful, in particular, if several software quality measures have to be related to each other or to components of a software or system. For example, software maps represent a specialized approach that "can express and combine information about software development, software quality, and system dynamics".[12]

Software quality also plays a role in the release phase of a software project. Specifically, the quality and establishment of the release processes (also patch processes),[13][14] configuration management[15] are important parts of an overall software engineering process.[16][17][18]

  1. ^ "Learning from history: The case of Software Requirements Engineering – Requirements Engineering Magazine". Learning from history: The case of Software Requirements Engineering – Requirements Engineering Magazine. Retrieved 2021-02-25.
  2. ^ Pressman, Roger S. (2005). Software Engineering: A Practitioner's Approach (Sixth International ed.). McGraw-Hill Education. p. 388. ISBN 0071267824.
  3. ^ "About the Automated Source Code Quality Measures Specification Version 1.0". www.omg.org. Retrieved 2021-02-25.
  4. ^ "How to Perform End-to-End Testing". smartbear.com. Retrieved 2021-02-25.
  5. ^ "How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations" (PDF). Archived (PDF) from the original on 2013-12-28. Retrieved 2013-10-18.
  6. ^ Fundamentals of Software Architecture: An Engineering Approach. O'Reilly Media. 2020. ISBN 978-1492043454.
  7. ^ "ISO/IEC 25010:2011". ISO. Retrieved 2021-02-23.
  8. ^ Armour, Phillip G. (2012-06-01). "A measure of control". Communications of the ACM. 55 (6): 26–28. doi:10.1145/2184319.2184329. ISSN 0001-0782. S2CID 6059054.
  9. ^ Voas, J. (November 2011). "Software's secret sauce: the "-ilities" [software quality]". IEEE Software. 21 (6): 14–15. doi:10.1109/MS.2004.54. ISSN 1937-4194.
  10. ^ "Code Quality Standards | CISQ - Consortium for Information & Software Quality". www.it-cisq.org. Retrieved 2021-02-25.
  11. ^ "Software Sizing Standards | CISQ - Consortium for Information & Software Quality". www.it-cisq.org. Retrieved 2021-02-25.
  12. ^ J. Bohnet, J. Döllner Archived 2014-04-27 at the Wayback Machine, "Monitoring Code Quality and Development Activity by Software Maps". Proceedings of the IEEE ACM ICSE Workshop on Managing Technical Debt, pp. 9-16, 2011.
  13. ^ "IIA - Global Technology Audit Guide: IT Change Management: Critical for Organizational Success". na.theiia.org. Retrieved 2021-02-26.
  14. ^ Boursier, Jérôme (2018-01-11). "Meltdown and Spectre fallout: patching problems persist". Malwarebytes Labs. Retrieved 2021-02-26.
  15. ^ "Best practices for software updates - Configuration Manager". docs.microsoft.com. Retrieved 2021-02-26.
  16. ^ Wright, Hyrum K. (2009-08-25). "Release engineering processes, models, and metrics". Proceedings of the doctoral symposium for ESEC/FSE on Doctoral symposium. ESEC/FSE Doctoral Symposium '09. Amsterdam, the Netherlands: Association for Computing Machinery. pp. 27–28. doi:10.1145/1595782.1595793. ISBN 978-1-60558-731-8. S2CID 10483918.
  17. ^ van der Hoek, André; Hall, Richard S.; Heimbigner, Dennis; Wolf, Alexander L. (November 1997). "Software release management". ACM SIGSOFT Software Engineering Notes. 22 (6): 159–175. doi:10.1145/267896.267909. ISSN 0163-5948.
  18. ^ Sutton, Mike; Moore, Tym (2008-07-30). "7 Ways to Improve Your Software Release Management". CIO. Retrieved 2021-02-26.