measurement Comparison Table

Object Oriented Software Engineering View all facts Glossary Help

subject > measurement

Next subject: mechanism Up: subject Previous subject: look and feel

measurement comparison table

Subject solve change measure in consist of observe by specify as over-constrain cut increase by is a subtopic of lead to affect by measure have precedence table gather from has part depends on reduce evaluate on influence by obtain from express as is a synonym of reduce by constrain by imply have example give measure as is a kind of agree upon by specify in terms of contribute to analysed group with describe in terms of depend on concern with improve by allow appear show as affect indirectly by indicate restrict have express in express using has definition describe have a direct impact on be

acceptability 7.4 - The Basics of User Interface Design many factors, including other aspects of usability, graphic design and various aesthetic issues how much users like the system software quality The extent to which customers and users like a system subjective

availability a customer's problem whenever the benefits of doing so outweigh the costs the design of the system if cost-benefit analysis shows that it will have minimum benefit but still cost a lot to develop 4.5 - Types of Requirements a system of sufficient quality - one that is sufficiently usable, safe, efficient, reliable and maintainable the amount of time that a server is running and available to respond to users various stakeholders, other software systems and any documentation that might be available problem statement a fact a unique number for traceability non-functional requirement all stakeholders if there is any doubt whether it is realistic other requirements into a requirements document a diagram how it will be implemented in order to give the designer as much freedom as possible to make decisions the freedom of software engineers as they make design decisions because it limits what resources can be used and sets bounds on aspects of the software's quality benefits that outweigh the costs of development a natural language such as English (using present tense and active voice), sometimes supplemented by a formal mathematical language, and often by some form of diagram clear and consistent notation, using language that the customers can understand, and consistent with the other requirements A quality that measures the amount of time that a system is running and able to provide services to its users a constraint that must be adhered to during development verifiable by measuring various aspects of the system and seeing if the measurements conform with the requirement

cohesion 9.2 - Principles Leading to Good Design
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.
software quality 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 hard to assess

coupling 9.2 - Principles Leading to Good Design that if you want to reuse one component, you will also have to import all the ones with which it is coupled software quality A measure of the extent to which interdependencies exist between software modules hard to assess

coverage 10.3 - Defects in Ordinary Algorithms measurement A measure of the percentage of paths, statements or branches taken by a set of tests

earned value 11.5 - Project Scheduling and Tracking budgeted cost of work performed measurement The amount of work completed, measured according to the budgeted effort that the work was supposed to consume

efficiency stakeholders 1.5 - Software Quality how much CPU-time, memory, disk-space, network bandwidth or other resources software uses software architecture measurement The extent to which a product or process can operate using the fewest possible resources stakeholders important to customers in order to reduce their costs of running the software

efficiency of use 7.4 - The Basics of User Interface Design 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 software quality ordinary use A measure of how fast an expert user can do their work using the system hard to assess

error handling 7.4 - The Basics of User Interface Design how well the system prevents the user from making errors, detects errors, and helps the user to correct errors software quality abnormal situations better if the system effectively prevents the user from making errors, detects errors, and helps the user to correct errors

error^3 10.1 - Basic Definitions measurement An inaccuracy in a numerical computation bad only if it is not anticipated and correctly handled

learnability 7.4 - The Basics of User Interface Design how fast a new user can learn the system information overload 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 software quality learning curves ordinary use having fewer things to learn, or by making the learning process more intuitive The speed with which a new user can become proficient with the system hard to assess

learning curve 7.4 - The Basics of User Interface Design measurement A curve on a diagram that plots the time spent learning on one axis, and the amount of functionality learned on the other axis the learnability of software

maintainability stakeholders the use of modularity 1.5 - Software Quality complexity of code costs for both developers and customers software architecture measurement An important quality of software that measures the extent to which the software can be modified at the lowest possible cost the ease with which the software can be changed stakeholders hard to assess

metric 10.11 - Quality Assurance in General measurement A scale on which a software product or process may be measured

modularity 2.7 - Concepts that Define Object Orientation software quality maintainability The extent to which software is divided into components, called modules, which have high internal cohesion, low coupling between each other, and simple interfaces hard to assess

number of bugs 10.13 - Difficulties and Risks in Quality Assurance measurement proportional to the number of bugs remaining

number of defects found when inspecting a product 10.11 - Quality Assurance in General measurement

number of failures encountered by users 10.11 - Quality Assurance in General measurement

number of failures found when testing a product 10.11 - Quality Assurance in General measurement

number of questions posed by users to the help desk 10.11 - Quality Assurance in General measurement

number of use cases 7.3 - Developing Use Case Models of Systems measurement a project's complexity

objective 9.3 - Techniques for Making Good Design Decisions memory efficiency, CPU efficiency, maintainability, portability and usability non-functional requirements measurement A measurable value you wish to attain

percentage of code that is reused 10.11 - Quality Assurance in General measurement

person-month 11.3 - Cost Estimation effort measurement A measure of effort. One person month is the amount of work done by one person in one month if they are working full time

recovery from failure a customer's problem whenever the benefits of doing so outweigh the costs the maximum-allowed impact of a failure the design of the system if cost-benefit analysis shows that it will have minimum benefit but still cost a lot to develop 4.5 - Types of Requirements a system of sufficient quality - one that is sufficiently usable, safe, efficient, reliable and maintainable various stakeholders, other software systems and any documentation that might be available problem statement a fact for a word processing program: The system will allow users to continue their work after a failure with the loss of no more than 20 words of typing or 20 formatting commands a unique number for traceability non-functional requirement all stakeholders if there is any doubt whether it is realistic other requirements into a requirements document a diagram how it will be implemented in order to give the designer as much freedom as possible to make decisions the freedom of software engineers as they make design decisions because it limits what resources can be used and sets bounds on aspects of the software's quality benefits that outweigh the costs of development a natural language such as English (using present tense and active voice), sometimes supplemented by a formal mathematical language, and often by some form of diagram clear and consistent notation, using language that the customers can understand, and consistent with the other requirements a constraint that must be adhered to during development verifiable by measuring various aspects of the system and seeing if the measurements conform with the requirement

reliability a customer's problem whenever the benefits of doing so outweigh the costs stakeholders the average amount of time between failures or the probability of a failure in a given period the design of the system if cost-benefit analysis shows that it will have minimum benefit but still cost a lot to develop 4.5 - Types of Requirements a system of sufficient quality - one that is sufficiently usable, safe, efficient, reliable and maintainable complexity of code various stakeholders, other software systems and any documentation that might be available problem statement the number of mistakes made by the software engineers who developed the software a fact a unique number for traceability non-functional requirement all stakeholders if there is any doubt whether it is realistic other requirements into a requirements document ensuring the software is easy to implement and change, and also ensuring that if failures occur, the system can handle them or can recover easily a diagram commenting how it will be implemented in order to give the designer as much freedom as possible to make decisions the freedom of software engineers as they make design decisions because it limits what resources can be used and sets bounds on aspects of the software's quality benefits that outweigh the costs of development a natural language such as English (using present tense and active voice), sometimes supplemented by a formal mathematical language, and often by some form of diagram clear and consistent notation, using language that the customers can understand, and consistent with the other requirements An important quality of software that measures the frequency of failures, as encountered by testers and end-users a constraint that must be adhered to during development stakeholders more important than efficiency in a safety-critical system

requirement stability 11.3 - Cost Estimation measurement A measure of the extent to which requirements are likely to change

resource usage a customer's problem whenever the benefits of doing so outweigh the costs the design of the system if cost-benefit analysis shows that it will have minimum benefit but still cost a lot to develop 4.5 - Types of Requirements a system of sufficient quality - one that is sufficiently usable, safe, efficient, reliable and maintainable various stakeholders, other software systems and any documentation that might be available problem statement a fact you could specify that no more than a certain amount of memory is to be used by the system, and that the system must consume less than 10% of the CPU's time a unique number for traceability non-functional requirement all stakeholders the maximum amount of these resources that the system will consume if there is any doubt whether it is realistic other requirements into a requirements document others to efficiently plan hardware upgrades a diagram how it will be implemented in order to give the designer as much freedom as possible to make decisions the freedom of software engineers as they make design decisions because it limits what resources can be used and sets bounds on aspects of the software's quality benefits that outweigh the costs of development a natural language such as English (using present tense and active voice), sometimes supplemented by a formal mathematical language, and often by some form of diagram clear and consistent notation, using language that the customers can understand, and consistent with the other requirements a constraint that must be adhered to during development verifiable by measuring various aspects of the system and seeing if the measurements conform with the requirement

response time a customer's problem whenever the benefits of doing so outweigh the costs the design of the system if cost-benefit analysis shows that it will have minimum benefit but still cost a lot to develop 7.5 - Usability Principles a system of sufficient quality - one that is sufficiently usable, safe, efficient, reliable and maintainable various stakeholders, other software systems and any documentation that might be available problem statement the slowest hardware that end-users are likely to encounter a fact a unique number for traceability non-functional requirement all stakeholders if there is any doubt whether it is realistic other requirements into a requirements document instantaneous for some operations such as tracking the cursor, popping up of menus and echoing of input a diagram how it will be implemented in order to give the designer as much freedom as possible to make decisions the freedom of software engineers as they make design decisions because it limits what resources can be used and sets bounds on aspects of the software's quality benefits that outweigh the costs of development a natural language such as English (using present tense and active voice), sometimes supplemented by a formal mathematical language, and often by some form of diagram clear and consistent notation, using language that the customers can understand, and consistent with the other requirements The time that elapses from when a user issues a command to when the system provides enough results so the user can continue his or her work a constraint that must be adhered to during development more than 15-20 seconds unless the user interface warns the user so the user can do something else while waiting or choose not to perform the operation

reusability stakeholders 9.2 - Principles Leading to Good Design software architecture measurement A quality that measures of the extent to which a product or process can be used in different contexts from which it was originally designed stakeholders hard to assess

schedule^2 11.3 - Cost Estimation measurement The total elapsed time of a project

severity level 10.8 - Writing Formal Test Cases and Test Plans measurement A number given to a failure, defect or test case, indicating the amount of impact it has on the user or customer

test case pass target 10.9 - Strategies for Testing Large Systems
in a non critical system used by a small number of people, 95% for level 2 and 75% for level 3
in a critical system, or one used by a large number of people, 99% for level 2, and 90% for level 3
measurement the cost of failures vs. the cost of continued testing and fixing of defects The desired percentage of test cases that will pass testing

throughput a customer's problem whenever the benefits of doing so outweigh the costs the design of the system if cost-benefit analysis shows that it will have minimum benefit but still cost a lot to develop 4.5 - Types of Requirements a system of sufficient quality - one that is sufficiently usable, safe, efficient, reliable and maintainable various stakeholders, other software systems and any documentation that might be available problem statement a fact a unique number for traceability non-functional requirement all stakeholders computations or transactions per minute if there is any doubt whether it is realistic other requirements into a requirements document a diagram how it will be implemented in order to give the designer as much freedom as possible to make decisions the freedom of software engineers as they make design decisions because it limits what resources can be used and sets bounds on aspects of the software's quality benefits that outweigh the costs of development a natural language such as English (using present tense and active voice), sometimes supplemented by a formal mathematical language, and often by some form of diagram clear and consistent notation, using language that the customers can understand, and consistent with the other requirements a constraint that must be adhered to during development verifiable by measuring various aspects of the system and seeing if the measurements conform with the requirement

traceability 4.8 - Reviewing Requirements software quality The ability to determine the information that led to a decision being made important because design documents to be able to say which requirement is being implemented by a given aspect of the design

usefulness the context of particular types of users utility^2 and usability stakeholders 7.4 - The Basics of User Interface Design measurement The extent to which a system can be used to perform a task; combines usability and utility^2 stakeholders essential

Next subject: mechanism Up: subject Previous subject: look and feel