|
When applied to software the adjective quality may apply to source code as seen by software developers, or to applications software as seen by the end-users of the software. Image File history File links Broom_icon. ...
A computer program is a collection of instructions that describe a task, or set of tasks, to be carried out by a computer. ...
For the Talib Kweli album Quality (album) Quality can refer to a. ...
Source code (commonly just source or code) is any series of statements written in some human-readable computer programming language. ...
In computing, a programmer is someone who does computer programming and develops computer software. ...
Application software is a loosely defined subclass of computer software that employs the capabilities of a computer directly to a task that the user wishes to perform. ...
Software quality is defined very differently by various experts in the field. One common definition, coined by Gerald Weinberg in his book Quality Software Management: Systems Thinking v. 1 is "Quality is value to some person." This definition stresses that quality is inherently subjective - different people will experience the quality of the same software very differently. One strength of this definition is the questions it invites software teams to consider, such as "Who are the people we want to value our software?", and "What will be valuable to them?". Gerald Marvin Weinberg is an author and teacher of the psychology and anthropology of computer software development. ...
The definition of quality as fitness for purpose means that the purpose of the software needs to be used to deduce those attributes that should be used to measure its quality.
History
Software product quality In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the requirements of a new or altered system, taking account of the possibly conflicting requirements of the various stakeholders, such as users. ...
A program specification is the definition of what a computer program is expected to do. ...
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. ...
It has been suggested that this article or section be merged with Scale (computing). ...
In theoretical computer science, correctness of an algorithm is asserted when it is said that the algorithm is correct with respect to a specification. ...
In mathematics and related technical fields, a mathematical object is complete if nothing needs to be added to it. ...
A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working as intended, or produces an incorrect result. ...
In computer science, Fault-tolerance is the property of a computer system to continue operation at an acceptable quality, despite the unexpected occurrence of hardware or software failures. ...
Extensibility is a system design principle where the current implementation takes into consideration future growth. ...
In telecommunication, the term maintainability has the following meanings: A characteristic of design and installation, expressed as the probability that an item will be retained in or restored to a specified condition within a given period of time, when the maintenance is performed in accordance with prescribed procedures and resources. ...
In general terms, documentation is any communicable material (such as text, video, audio, etc. ...
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. Programming style refers to a set of rules or guidelines used when writing the source code for a computer program. ...
Methods to improve the quality: refactoring. Look up readability in Wiktionary, the free dictionary. ...
In software engineering, software maintenance is the process of enhancing and optimizing deployed software (software release), as well as remedying defects. ...
Software testing is the process used to measure the quality of developed computer software. ...
Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware thus making it behave as expected. ...
Complexity in general usage is the opposite of simplicity. ...
This article or section does not cite any references or sources. ...
Die of an Intel 80486DX2 microprocessor (actual size: 12×6. ...
Lint is a computer programming tool that performs the lexical and syntactic portions of the compilation with substantial additional checks, noting when variables had been used before being set, when they were used as a datatype other than that of their definition, and numerous other programming errors. ...
Refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly keeping its meaning or behavior. ...
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. Reliability engineering is the discipline of ensuring that a system (or a device in general) will perform its intended function(s) when operated in a specified manner for a specified length of time. ...
It has been suggested that this article or section be merged with Computer program. ...
A software metric is a measure of some property of a piece of software or its specifications. ...
With software embedded into many devices today, software failure has caused more than inconvenience. Software errors have even caused human fatalities. 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 [1] (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. It has been suggested that Embedded System Design in an FPGA be merged into this article or section. ...
A software bug (or bug) is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e. ...
FDA logo The Food and Drug Administration (FDA) is an agency of the United States Department of Health and Human Services and is responsible for regulating food, dietary supplements, drugs, biological medical products, blood products, medical devices, radiation-emitting devices, veterinary products, and cosmetics in the United States. ...
“FAA†redirects here. ...
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, 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. This article or section does not cite its references or sources. ...
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 known 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 rein 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. In theoretical computer science, correctness of an algorithm is asserted when it is said that the algorithm is correct with respect to a specification. ...
In theoretical computer science, automata theory is the study of abstract machines and problems they are able to solve. ...
Reliability in program development
Requirements A program cannot be expected to work as desired if the developers of the program do not, in fact, know the program's desired behaviour in advance, or if they cannot at least determine its desired behaviour in parallel with development, in sufficient detail. What level of detail is considered sufficient is hotly debated. The idea of perfect detail is attractive, but may be impractical, if not actually impossible, in practice. This is because the desired behaviour tends to change as the possible range of the behaviour is determined through actual attempts, or more accurately, failed attempts, to achieve it.
Whether a program's desired behaviour can be successfully specified in advance is a moot point if the behaviour cannot be specified at all, and this is the focus of attempts to formalize the process of creating requirements for new software projects. In situ with the formalization effort is an attempt to help inform non-specialists, particularly non-programmers, who commission software projects without sufficient knowledge of what computer software is in fact capable. Communicating this knowledge is made more difficult by the fact that, as hinted above, even programmers cannot always know in advance what is actually possible for software in advance of trying.
Design While requirements are meant to specify what a program should do, design is meant, at least at a high level, to specify how the program should do it. The usefulness of design is also questioned by some, but those who look to formalize the process of ensuring reliability often offer good software design processes as the most significant means to accomplish it. Software design usually involves the use of more abstract and general means of specifying the parts of the software and what they do. As such, it can be seen as a way to break a large program down into many smaller programs, such that those smaller pieces together do the work of the whole program. Software design is the process that starts from a problem for which there is currently no acceptable (software) solution, and ends when such a solution has been created. ...
The purposes of high-level design are as follows. It separates what are considered to be problems of architecture, or overall program concept and structure, from problems of actual coding, which solve problems of actual data processing. It applies additional constraints to the development process by narrowing the scope of the smaller software components, and thereby — it is hoped — removing variables which could increase the likelihood of programming errors. It provides a program template, including the specification of interfaces, which can be shared by different teams of developers working on disparate parts, such that they can know in advance how each of their contributions will interface with those of the other teams. Finally, and perhaps most controversially, it specifies the program independently of the implementation language or languages, thereby removing language-specific biases and limitations which would otherwise creep into the design, perhaps unwittingly on the part of programmer-designers. Data processing is any computer process that converts data into information or knowledge. ...
Software component representations: above the representation used in UML, below the representation commonly used by Microsofts COM objects. ...
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. A programming language is an artificial language that can be used to control the behavior of a machine, particularly a computer. ...
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 Given a whole or partial program, it is possible to perform manual or automated tests to determine if the program fulfills its behavioural requirements.
Unit tests are tests which are created to be run on small sections of code, usually one or another form of sub-routine, and usually in the context of abstract data types, to ensure the operations on those types proceed as desired. In computer programming, a unit test is a procedure used to validate that a particular module of source code is working properly. ...
Integration tests are meant to prove or disprove that larger modules of code work correctly with one another. These tests are often performed with the help of a harness, which is a piece of software which imitates a code module in shape, but which contains only testing code for the purpose of interfacing with another real module to evaluate its operation in a setting one step closer to the intended final production environment. Integration testing is the phase of software testing in which individual software modules are combined and tested as a group. ...
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..... In computer science, runtime or run time describes the operation of a computer program, the duration of its execution, from beginning to termination (compare compile time). ...
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. Image File history File links Information. ...
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 user interface (UI), which for best usability is usually graphical (i.e. a 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 There are varied perspectives within the field on measurement. There are a great many measures that are valued by some professionals, or in some contexts, that are decried as harmful by others. Some believe that quantitative measures of software quality are essential. Others believe that contexts where quantitative measures are useful are quite rare, and so prefer qualitative measures. Several leaders in the field of software testing have written about the difficulty of measuring what we truly want to measure well, including Dr. Cem Kaner [2](PDF) and Douglass Hoffman [3](PDF). Software testing is the process used to measure the quality of developed computer software. ...
One example of a popular metric is the number of faults encountered in the software. Software that contains few faults is considered by some to have higher quality than software that contains many faults. Questions that can help determine the usefulness of this metric in a particular context include: A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working as intended, or produces an incorrect result. ...
- What constitutes 'many faults'? Does this differ depending on the purpose of the software (e.g. blogging software v. navigational software)? Does this take into account the size and complexity of the software?
- Does this account for the importance of the bugs (and the importance to the stakeholders of the people those bugs bug)? Does one try to weight this measure by the severity of the fault, or the incidence of users it effects? If so, how? And if not, how does one know that 100 faults discovered in better than 1000?
- If the count of faults being discovered is shrinking, how do I know what that means? For example, does that mean that the product is now higher quality that it was before? Or that this is a smaller/less ambitious change than before? Or that less tester-hours have gone into the project than before? Or that this project was tested by less skilled testers than before? Or that the team has discovered that less faults reported is in their interest?
This last question points to an especially difficult one to manage. All software quality metrics are in some sense measures of human behavior, since humans create software[4](PDF). If a team discovers that they will benefit from a drop in the number of reported bugs, there is a strong tendency for the team to start reporting less defects. That may mean that email begins to circumvent the bug tracking system, or that four or five bugs get lumped into one bug report, or that testers learn not to report minor annoyances. The difficulty is measuring what we mean to measure, without creating incentives for software programmers and testers to consciously or unconsciously "game" the measurements.
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 Are variable names descriptive of the physical or functional property represented? Do uniquely recognisable functions contain adequate comments so that their purpose is clear? Are deviations from forward logical flow adequately commented? Are all elements of an array functionally related?.. b
Completeness
Conciseness Is all code reachable? Is any code redundant? How many statements within loops could be placed outside the loop, thus reducing computation time? Are branch decisions too complex?
Portability - Does the program depend upon system or library routines unique to a particular installation? Have machine-dependent statements been flagged and commented? Has dependency on internal bit representation of alphanumeric or special characters been avoided?
- The effort required to transfer the program from one hardware/software system environment to another.
Consistency Is one variable name used to represent different physical entities in the program? Does the program contain only one representation for physical or mathematical constants? Are functionally similar arithmetic expressions similarly constructed? Is a consistent scheme for indentation used?
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 Is a GUI used? Is there adequate on-line help? Is a user manual provided? Are meaningful error messages provided?
Reliability - Are loop indexes range tested? Is input data checked for range errors? Is divide-by-zero avoided? Is exception handling provided?
- The extent to which a program can be expected to perform its intended function with rescission
Structuredness Is a block-structured programming language used? Are modules limited in size? Have the rules for transfer of control between modules been established and followed?
Efficiency - Have functions been optimized for speed? Have repeatedly used blocks of code been formed into sub-routines? Checked for any memory leak, overflow?
- The amount of computing resources and code required by a program to perform its function.
Security Does the software protect itself and its data against unauthorized access and use? Does it allow its operator to enforce security policies? Are appropriate security mechanisms in place? Are those security mechanisms implemented correctly? Can the software withstand attacks that must be expected in its intended environment? Is the software free of errors that would make it possible to circumvent its security mechanisms? Does the architecture limit the impact of yet unknown errors?
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 called usability. It is hard to quantify the usability of a given software product. Some important questions to be asked are: Usability is a term used to denote the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal. ...
- Is the user interface intuitive?
- Is it easy to perform easy operations?
- Is it feasible 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. This page is a candidate for speedy deletion. ...
A widget (or control) is an interface component that a computer user interacts with, such as a window or a text box. ...
Software Documentation or Source Code Documentation is written text that accompanies computer software. ...
In computer science, self-documenting refers to the ability of a piece of code or something else to require users have little or no previous knowledge of its specification, purpose and behavior to use it effectively. ...
See also ISO 9126 is an international standard for the evaluation of software. ...
ISO 15504 is a standard for Process Assessment. ...
Software testing is the process used to measure the quality of developed computer software. ...
For the Talib Kweli album Quality (album) Quality can refer to a. ...
For the Jurassic 5 album, see Quality Control (album) In engineering and manufacturing, quality control and quality engineering are involved in developing systems to ensure products or services are designed and produced to meet or exceed customer requirements. ...
Total Quality Management (TQM) is a management strategy aimed at embedding awareness of quality in all organizational processes. ...
Capability Maturity Model (CMM) broadly refers to a process improvement approach that is based on a process model. ...
Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. ...
Performance engineering is the set of roles, skills, activities, practices, tools, and deliverables applied at every phase of the Systems Development Lifecycle which ensures that a solution will be designed and implemented to meet the non-functional requirements defined for the solution. ...
The braces are included in the comment in order to help distinguish this use of a comment from other uses. ...
Splint, short for Secure Programming Lint, is a programming tool for statically checking C programs for security vulnerabilities and coding mistakes. ...
In computing, optimization is the process of modifying a system to make some aspect of it work more efficiently or use fewer resources. ...
In computer science, efficiency is used to describe several desirable properties of an algorithm or other construct, besides clean design, functionality, etc. ...
In software engineering, performance analysis (a field of dynamic program analysis) is the investigation of a programs behavior using information gathered as the program runs, as opposed to static code analysis. ...
To meet Wikipedias quality standards, this article or section may require cleanup. ...
A programming paradigm is a paradigmatic style of programming (compare with a methodology, which is a paradigmatic style of doing software engineering). ...
Programming style refers to a set of rules or guidelines used when writing the source code for a computer program. ...
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships between them. ...
A software metric is a measure of some property of a piece of software or its specifications. ...
It has been suggested that essential complexity be merged into this article or section. ...
In computer programming, cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. ...
In computer science, coupling or dependency is the degree to which each program module relies on each other module. ...
Software standards enable software to interoperate. ...
In computer science and software engineering, reusability is the likelihood a segment of structured code can be used again to add new functionalities with slight or no modification. ...
Within systems engineering, -ilities are aspects or non-functional requirements. ...
Accessibility is a general term used to describe the degree to which a system is usable by as many people as possible. ...
In telecommunications and reliability theory, the term availability has the following meanings: 1. ...
In computer science, dependability is defined as [1] Dependability includes the following attributes of a computing system [2]: Availability: readiness for correct service; Reliability: continuity of correct service; Safety: absence of catastrophic consequences on the user(s) and the environment; Security: the concurrent existence of (a) availability for authorized users...
This article needs additional references or sources for verification. ...
Security engineering is the field of engineering dealing with the security and integrity of real-world systems. ...
A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working as intended, or produces an incorrect result. ...
Look up anomaly in Wiktionary, the free dictionary. ...
Software quality can be defined as conformance to requirements and/or fitness of use. Quality achievements start with a loud and clear definition of what quality of source code means to your organization or project. ...
Software testing is the process used to help identify the correctness, completeness, security and quality of developed computer software. ...
SQO-OSS (Software Quality Observatory for Open Source Software) is an IST-funded initiative [1] aiming to create a platform and the associated tools to measure the quality of software. ...
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.
|
Feeds |
Contact