Object Oriented Software Engineering   View all facts   Glossary   Help

subject > criterion > quality > software quality

software quality comparison table

Subject	increase by	describe in terms of	have an effect on	imply	measure	affect by	be	is a subtopic of	have example	has part	has definition	measure as	observe by	have precedence table	reduce by	concern with	have a direct impact on	improve by	get power from	exist	contribute to	measure by
abstraction^2	fewer public methods in each class all variables being private the use of superclasses methods or operations having fewer parameters						hard to assess	9.2 - Principles Leading to Good Design			The quality of software in which only the essential aspects of something are captured, reducing the complexity apparent to the user
acceptability					how much users like the system	many factors, including other aspects of usability, graphic design and various aesthetic issues	subjective	7.4 - The Basics of User Interface Design			The extent to which customers and users like a system
cohesion							hard to assess	9.2 - Principles Leading to Good Design			A measure of the extent to which related aspects of a system are kept together in the same module, and unrelated aspects are kept out			Cohesion type Comments functional cohesion If an aspect of a design can be achieved using a functionally cohesive module then it is normally best to do so. layer cohesion Layer cohesion should typically have higher priority. Dividing systems into layers has been shown to considerably simplify systems. communicational cohesion Communicational cohesion, as embodied in the classes of an object oriented system, should have high priority. Here we list it below layer cohesion since modules may access the same kind of data in different layers. sequential cohesion Sequential cohesion is effectively a strong form of temporal cohesion, but is weaker than communicational cohesion since different data types may be involved in the different stages of a sequentially cohesive module. temporal cohesion Temporal cohesion should typically be considered weaker than other types of cohesion. It is important, but only if the other types of cohesion have been achieved. utility cohesion Utility cohesion is the weakest kind of cohesion since it serves to group together those parts of the system that do not seem to logically belong anywhere else.
coupling				that if you want to reuse one component, you will also have to import all the ones with which it is coupled			hard to assess	9.2 - Principles Leading to Good Design			A measure of the extent to which interdependencies exist between software modules
effectiveness of a system at handling errors							hard to assess	7.4 - The Basics of User Interface Design		effectiveness of error prevention
effectiveness of error correction							hard to assess	7.4 - The Basics of User Interface Design				the amount of time that elapses from the appearance of each error message, to the time when the user has corrected the error
effectiveness of error detection							hard to assess	7.4 - The Basics of User Interface Design				the fraction of errors that users notice
effectiveness of error prevention							hard to assess	7.4 - The Basics of User Interface Design														recording the frequency with which error messages appear
efficiency of use					how fast an expert user can do their work using the system		hard to assess	7.4 - The Basics of User Interface Design			A measure of how fast an expert user can do their work using the system	the total number of instances of a small task that a user can do per hour, or the total time required to do a certain large task				ordinary use
error handling					how well the system prevents the user from making errors, detects errors, and helps the user to correct errors		better if the system effectively prevents the user from making errors, detects errors, and helps the user to correct errors	7.4 - The Basics of User Interface Design								abnormal situations
external software quality							hard to assess	1.5 - Software Quality					stakeholders				stakeholders
identity							hard to assess	2.7 - Concepts that Define Object Orientation			The characteristic of having a distinct existence, such that each entity can be uniquely referred to
internal software quality			external quality attributes				hard to assess	1.5 - Software Quality			A software quality that characterize aspects of the design of the software
learnability		learning curves			how fast a new user can learn the system		hard to assess	7.4 - The Basics of User Interface Design	a user might be able to learn the most important 20% of the system in 3 days if the system is simple and intuitive; 7 days if the system is simple but non-intuitive, and 11 days if the system is complex and non-intuitive		The speed with which a new user can become proficient with the system				information overload	ordinary use		having fewer things to learn, or by making the learning process more intuitive
modularity							hard to assess	2.7 - Concepts that Define Object Orientation			The extent to which software is divided into components, called modules, which have high internal cohesion, low coupling between each other, and simple interfaces										maintainability
polymorphism							one of the fundamental features of the object oriented paradigm	2.4 - Methods, Operations and Polymorphism			A property of object oriented software by which an abstract operation may be performed in different ways in different classes								dynamic binding	when several classes which each implement the operation either have a common superclass in which the operation exists, or else implement an interface that contains the operation
portability							hard to assess	9.2 - Principles Leading to Good Design			The ability for software to be run in a variety of different hardware or software environments with no or minimal changes
testability							hard to assess	9.2 - Principles Leading to Good Design			The ability for software to be instrumented so that it can be automatically tested using a test harness
traceability							important because design documents to be able to say which requirement is being implemented by a given aspect of the design	4.8 - Reviewing Requirements			The ability to determine the information that led to a decision being made

Next quality: atomicity    Up: quality    Previous quality: ripple effect