article

Quality of software is a conformance to requirements. Set of requirements is very wide: for example readability,fault-tolerance.

Anti-patterns are common problems that happen frequently in computer programming and that should be avoided to achieve quality.

History

Software product quality

Source code quality

To a computer, there is no real concept of "well-written" source code. However, to a human, the way a program is written can have some important consequences for the human maintainers. Many source code programming style guides, which stress readability and some language-specific conventions are aimed at the maintenance of the software source code, which involves debugging and updating. Other issues also come into considering whether code is well written, such as the logical structuring of the code into manageable sections.

Methods to improve the quality: refactoring.

Software reliability

Software reliability is one of a number of aspects of computer software which can be taken into consideration when determining the quality of the software. Although the term "quality" could connote a subjective — as in, qualitative — evaluation, software reliability is generally meant to be measured using objective criteria. These measured criteria are typically called metrics. Then again, much of the real work in improving the reliability of software has been practical, evolutionary and even ad hoc, brought on by the pressures of making software development manageable and even comprehensible, not to mention profitable. It is thought by some that the last requirement will become the driving force of future reliability improvement efforts as competition in the software development industry reaches new heights of intensity, and as users become more frustrated with software which fails to meet up to growing expectations.

With software embedded into many devices today, software failure has caused more than inconvenience. Software errors have caused human death. The causes have ranged from poorly designed user interfaces to direct programming errors. An example of a programming error that lead to multiple deaths is discussed in Dr. Leveson's paper * (PDF). This has resulted in requirements for development of some types software. In the United States, both the Food and Drug Administration (FDA) and Federal Aviation Administration (FAA) have requirements for software development.

The goal of reliability

The need for a means to objectively determine software quality comes from the desire to apply the techniques of contemporary engineering fields to the development of software. That desire is a result of the common observation, by both lay-persons and specialists, that computer software does not work the way it ought to. In other words, software is seen to exhibit undesirable behaviour, up to and including outright failure, with consequences for the data which is processed, the machinery on which the software runs, and by extension the people and materials which those machines might negatively affect. The more critical the application of the software to economic and production processes, or to life-sustaining systems, the more important is the need to assess the software's reliability.

Regardless of the criticality of any single software application, it is also more and more frequently observed that software has penetrated deeply into most every aspect of modern life through the technology we use. It is only expected that this infiltration will continue, along with an accompanying dependency on the software by the systems which maintain our society. As software becomes more and more crucial to the operation of the systems on which we depend, the argument goes, it only follows that the software should offer a concomitant level of dependability. In other words, the software should behave in the way it is intended, or even better, in the way it should.

The challenge of reliability

The circular logic of the preceding sentence is not accidental — it is meant to illustrate a fundamental problem in the issue of measuring software reliability, which is the difficulty of determining, in advance, exactly how the software is intended to operate. The problem seems to stem from a common conceptual error in the consideration of software, which is that software in some sense takes on a role which would otherwise be filled by a human being. This is a problem on two levels. Firstly, most modern software performs work which a human could never perform, especially at the high level of reliability that is often expected from software in comparison to humans. Secondly, because software is fundamentally incapable of most of the mental capabilities of humans which separate them from mere mechanisms: qualities such as adaptability, general-purpose knowledge, a sense of conceptual and functional context, and common sense.

Nevertheless, most software programs could safely be considered to have a particular, even singular purpose. If the possibility can be allowed that said purpose can be well or even completely defined, it should present a means for at least considering objectively whether the software is, in fact, reliable, by comparing the expected outcome to the actual outcome of running the software in a given environment, with given data. Unfortunately, it is still not know whether it is possible to exhaustively determine either the expected outcome or the actual outcome of the entire set of possible environment and input data to a given program, without which it is probably impossible to determine the program's reliability with any certainty.

However, various attempts are in the works to attempt to reign in the vastness of the space of software's environmental and input variables, both for actual programs and theoretical descriptions of programs. Such attempts to improve software reliability can be applied at different stages of a program's development, in the case of real software. These stages principally include: requirements, design, programming, testing, and runtime evaluation. The study of theoretical software reliability is predominantly concerned with the concept of correctness, a mathematical field of computer science which is an outgrowth of language and automata theory.

Reliability in program development

Requirements

Then, we’ll investigate the relationship that patterns have had on OOD and OO testing. Starting with the seminal work by the Gang of Four (Gamma, Helm, Johnson and Vlissides) in 1995, OO development was changed. Their recognition that problems once solved, and solved well, could have the solutions applied to other problems of a similar nature affected OO development greatly. Building on the concept of patterns applied to the OO development process, Binder and others started creating patterns for the testing portion of OO projects. We will investigate some of the patterns and cover one in detail in an attempt to better understand how patterns work in Object-Oriented Testing.

Design

The reality of OO testing is that it is more necessary than ever because of the reusability of the objects and other aspects of OOD. If a problem exists in an object or class, that problem can potentially be spread throughout hundreds or thousands of programs. The impact could be significant. Additionally, testers must be familiar with intricacies of OOD in order to fully test an OO project. Binder mentions some of his perceived additional hurdles for testers when speaking about inheritance. Just because an object is derived from a known or trusted superclass does not mean that we don’t need to test the subclass. “Subclasses create new ways to misuse inherited features.”(Binder, 1995) Encapsulation, polymorphism, inheritance etc. are all key parts of OOD projects and they each have their own dangers to convey to the testers of OO projects.

Programming

The history of computer programming language development can often be best understood in the light of attempts to master the complexity of computer programs, which otherwise becomes more difficult to understand in proportion (perhaps exponentially) to the size of the programs. (Another way of looking at the evolution of programming languages is simply as a way of getting the computer to do more and more of the work, but this may be a different way of saying the same thing.) Lack of understanding of a program's overall structure and functionality is a sure way to fail to detect errors in the program, and thus the use of better languages should, conversely, reduce the number of errors by enabling a better understanding.

Improvements in languages tend to provide incrementally what software design has attempted to do in one fell swoop: consider the software at ever greater levels of abstraction. Such inventions as statement, sub-routine, file, class, template, library, component and more have allowed the arrangement of a program's parts to be specified using abstractions such as layers, hierarchies and modules, which provide structure at different granularities, so that from any point of view the program's code can be imagined to be orderly and comprehensible.

In addition, improvements in languages have enabled more exact control over the shape and use of data elements, culminating in the abstract data type. These data types can be specified to a very fine degree, including how and when they are accessed, and even the state of the data before and after it is accessed..

Testing
The purpose of this workshop is to gain an understanding of what is involved in identifying tangible quality-carrying properties of components (including, programming language statements) that contribute to important high-level quality attributes. To do this we will use a mix of individual investigation and group and class discussion. You are advised to spend time on the individual step prior to the workshop session. This activity will serve as useful preparation for undertaking the first assignment.

Runtime

Runtime reliability determinations are similar to tests, but go beyond simple confirmation of behaviour to the evaluation of qualities such as performance and interoperability with other code or particular hardware configurations.

Software Quality Factors

A software quality factor is a non-functional requirement for a software program which is not called up by the customer's contract, but nevertheless is a desirable requirement which enhances the quality of the software program.

Some software quality factors are listed here:

Understandability is possessed by a software product if the purpose of the product is clear. This goes further than just a statement of purpose - all of the design and user documentation must be clearly written so that it is easily understandable. This is obviously subjective in that the user context must be taken into account, i.e. if the software product is to be used by software engineers it is not required to be understandable to the layman.

A software product possesses the characteristic completeness to the extent that all of its parts are present and each of its parts are fully developed. This means that if the code calls a sub-routine from an external library, the software package must provide reference to that library and all required parameters must be passed. All required input data must be available.

A software product possesses the characteristic conciseness to the extent that no excessive information is present. This is important where memory capacity is limited, and it is important to reduce lines of code to a minimum. It can be improved by replacing repeated functionality by one sub-routine or function which achieves that functionality. It also applies to documents.

A software product possesses the characteristic portability to the extent that it can be operated easily and well on multiple computer configurations. Portability can mean both between different hardware setups--such as running on a Mac as well as a PC--and between different operating systems--such as running on both Mac OS X and GNU/Linux.

A software product possesses the characteristic consistency to the extent that it contains uniform notation , symbology and terminology within itself.

A software product possesses the characteristic maintainability to the extent that it facilitates updating to satisfy new requirements. Thus the software product which is maintainable should be well-documented, not complex, and should have spare capacity for memory usage and processor speed.

A software product possesses the characteristic testability to the extent that it facilitates the establishment of acceptance criteria and supports evaluation of its performance. Such a characteristic must be built-in during the design phase if the product is to be easily testable - a complex design leads to poor testability.

A software product possesses the characteristic usability to the extent that it is convenient and practicable to use. This is affected by such things as the human-computer interface. The component of the software which has most impact on this is the graphical user interface (GUI).

A software product possesses the characteristic reliability to the extent that it can be expected to perform its intended functions satisfactorily. This implies a time factor in that a reliable product is expected to perform correctly over a period of time. It also encompasses environmental considerations in that the product is required to perform correctly in whichever conditions it finds itself - this is sometimes termed robustness.

A software product possesses Structuredness to the extent that it possesses a definite pattern of organisation in its constituent parts. A software product written in a block-structured language such as Pascal will satisfy this characteristic.

A software product possesses the characteristic efficiency to the extent that it fulfills its purpose without waste of resources. This means resources in the sense of memory utilisation and processor speed.

A software product possesses the characteristic security to the extent that it is able to protect data against unauthorized access and to withstand malicious interference with its operations. Besides presence of appropriate security mechanisms such as authentication, access control and encryption, security also implies reliability in the face of malicious, intelligent and adaptive attackers.

Measurement of software quality factors

Software Quality Factors cannot be measured because of their vague description. It is necessary to find measures , or metrics, which can be used to quantify them as non-functional requirements

For example, reliability is a software quality factor, but cannot be evaluated in its own right. However there are related attributes to reliability, which can indeed be measured. Such attributes are mean time to failure, rate of failure occurrence, availability of the system. Similarly, an attribute of portability is the number of target dependent statements in a program.

A scheme which could be used for evaluating software quality factors is given below. For every characteristic, there are a set of questions which are relevant to that characteristic. Some type of scoring formula could be developed based on the answers to these questions, from which a measure of the characteristic may be obtained.

Understandability

Identify what are the key tangible properties of selection statements and loop statments that impact the quality of software. For each property identify which high-level quality attributes from ISO-9126 (functionality, reliability, efficiency, useability, maintainability and portability) it impacts. In the case of variables you should be able to identify at least a half a dozen properties.

Completeness
Form groups of five and collate the findings of the group members. Add these responses to your individual collection.

Conciseness

To document your findings you may use a set of templates of the following form.

Portability

In the class discussion we will examine the various factors that have been found by the groups. What is not completed in class should be done as a private study exercise. 1. INDIVIDUAL

Consistency

In formulating your response draw on your experience in SE1 group assignments and definitions of software quality that have been provided.

Maintainability

Has some memory capacity been reserved for future expansion? Is the design cohesive, i.e., each module has recognisable functionality? Does the software allow for a change in data structures (object-oriented designs are more likely to allow for this)? If a functionally-based design (rather than object-oriented), is a change likely to require restructuring the main-program, or just a module?

Testability

Are complex structures employed in the code? Does the detailed design contain clear pseudo-code? Is the pseudo-code at a higher level of abstraction than the code? If tasking is used in concurrent designs, are schemes available for providing adequate test cases?

Usability

On the handout provided identify at least seven key factors that contribute to the quality of a software product. Rank each of the factors in decreasing order of importance. Use only a single line to identify each factor. One factor might be "a program follows the rules of structured programming" .

Reliability

Form groups of five and collate the various factors to identify the collective ranking. Again rank product and process factors from highest to lowest rank. Each member of the group should write down the groups' set of factors on the second sheet provided. In this step individuals may wish to try to convince their group of the importance of particular factors

Structuredness

Leaders of groups form groups of five and collate the various factors to identify the collective ranking. Again rank product and process factors from highest to lowest rank.

Efficiency
The purpose of this workshop is to identify key factors that contribute

Security

On the handout provided identify at least seven key processes that contribute to the effectiveness of producing quality software cost-effectively and on schedule. Rank each of the factors in decreasing order of importance.

User's perspective

In addition to the technical qualities of software, the end user's experience also determines the quality of software. This aspect of software quality is be called usability. It is hard to quantify the usability of a given software product. Some important questions to be asked are:

  • Is the user interface intuitive?
  • Is it easy to perform easy operations?
  • Is it feasable to perform difficult operations?
  • Does the software give sensible error messages?
  • Do widgets behave as expected?
  • Is the software well documented?
  • Is the user interface self-explanatory/ self-documenting?
  • Is the user interface responsive or too slow?

Also, the availability of (free or paid) support may determine the usability of software.

See also

Bibliography

  • International Organization for Standardization. Software Engineering — Product Quality — Part 1: Quality Model. ISO, Geneva, Switzerland, 2001. ISO/IEC 9126-1:2001(E).
  • Diomidis Spinellis. Code Quality: The Open Source Perspective. Addison Wesley, Boston, MA, 2006.
  • Ho-Won Jung, Seung-Gweon Kim, and Chang-Sin Chung. Measuring software product quality: A survey of ISO/IEC 9126. IEEE Software, 21(5):10–13, September/October 2004.
  • Stephen H. Kan. Metrics and Models in Software Quality Engineering. Addison-Wesley, Boston, MA, second edition, 2002.
  • Robert L. Glass. Building Quality Software. Prentice Hall, Upper Saddle River, NJ, 1992.

Software engineering

Softwarequalität | Qualità del software | Качество программного обеспечения | 软件质量

 

This article is licensed under the GNU Free Documentation License. It uses material from the "Software quality".

Home Page • arts • business • computers • games • health • hospitals • home • kids & teens • news • physicians • recreation• reference • regional • science • shopping • society • sports • world