Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 9: Software Quality Management - Coggle Diagram
Chapter 9: Software Quality Management
What Is Software Quality?
Crosby defines quality as "conformance to requirements." While one can debate the distinction between requirements, needs, and wants, quality definitions must consider the users' perspectives
PRODUCT QUALITY
Software product must provide functions of a type and at a time when the user needs them.
The product must work. If it has so many defects that it does not perform with reasonable consistency,
Beyond this quality threshold, however, the relative importance of defects as well as of usability, compatibility, functionality, and all the other "ilities"-depends on the user.
PROCESS QUALITY
The users are the software engineers and, for the PSP, this is you. The definition of a quality PSP is thus a PSP that meets your need to efficiently produce quality products.
The most obvious requirement is that the process consistently produces quality software.
The Economics of Software Quality
Software quality can be viewed as an economic issue.
Economics is thus an important quality issue not only because of this test decision but also because of the need to optimize life-cycle quality costs
THE COSTS OF FINDING AND FIXING DEFECTS
The cost of finding and fixing a defect includes each of the following elements:
Determining that there is a problem
Isolating the source of the problem Determining exactly what is wrong with the product
Fixing the requirements as needed
Fixing the design as needed
Fixing the implementation as needed Inspecting the fix to ensure it is correct
Testing the fix to ensure it fixes the identified problem
Testing the fix to ensure it doesn't cause other problems
Changing the documentation as needed to reflect the fix
TESTING SCHEDULES
The basic problem is the number of defects in the product at the start of test.
THE ECONOMICS OF DEFECT REMOVAL
The issue here is the economics of defect removal
Software engineers normally inject 100 or more defects per KLOC in their code. Some inject many more. While about half these defects are typically found by the compiler, the rest must be found either by inspections or by testing.
THE COST OF QUALITY
Quantify the size of the quality problem in language that will have impact on upper management
The cost of quality has three components
Failure costs: the costs of diagnosing a failure, making necessary repairs,and getting back into operation
Prevention costs: the costs associated with identifying the causes of the de- fects and the actions taken to prevent them in the future
Appraisal costs: the costs of evaluating the product to determine its quality level
PSP Cost of quaility meaures
Failure COQ
Appraisal COQ
Total COQ
Developing a Quality Strategy
As you develop a strategy for improving the quality of your programs, you should consider the following issues:
Decide how to measure your process.
Determine the quality methods that are most effective for you. 3. Periodically reevaluate your strategy and set new goals.
MEASURE YOUR PROCESS
The quality of the finished product is one important measure of process quality
The various review, inspection, and test phases then act as filters to remove a percentage of these defects. Your strategy should thus be to
Reduce the number of defects you inject
Improve the efficiency or yield of the filters
Ensure the filters inject as few defects as possible
Compound the number of filter stages to achieve the desired product quality. cost, and schedule.
DETERMINE THE MOST EFFECTIVE QUALITY METHODS
There are several ways to select a quality strategy. The most common is to focus on improving the product
A second way is to strive to improve the way you find and fix defects. This leads you to reviews, inspections, and checklists.
An appropriate strategy would involve the following actions:
Use the best requirements, design, implementation, and testing methods that you can find.
Continuously measure the ability of your process to produce quality products
Experiment with and measure the effectiveness of new tools and methods.
Incorporate into your process new tools and methods that improve your performance.
Yield Management
In thinking about the software process from a yield point of view, you should consider a number of factors
First, you can view the software process as the combination of two competing processes: defect injection and defect removal
The defect content of the product comes from the difference between these two processes. Thus relatively small changes in your process yield can cause large changes in the defect content of the finished program.
THE INJECTION PROCESS
To effectively manage software quality, you need to focus on both the removal and the injection processes. The basic defect causes fall into five categories as follows
Education: You did not understand how to do something.
Communication: You were not properly informed about something.
Oversight: You omitted doing something.
Transcription: You knew what to do but made a mistake in doing it.
Process: Your process somehow misdirected your actions.
Depending on your role, some of the questions you should consider are the following:
Was your task well enough planned to permit orderly work?
Were you motivated to do a quality job?
Was your PSP sufficiently defined to help you do quality work?
Was your development process supported with adequate tools and methods?
Defect Removal Strategies
The potential approaches are as follows:
Compound multiple defect removal phases so their combined yields produce an acceptable quality product.
Evaluate the cost and removal efficiency of these phases to achieve the most economical combination.
Measure, analyze, and manage these removal phases to guard against yield busts and to identify and react to them as quickly as possible.
Initiate a defect prevention process to gradually reduce the overall defect injection rate.
YIELD SPECIALIZATION BY PHASE
High-level design review:
Completeness of requirements coverage
System constraints
The system state machine
The class and object structures The allocation of system functions to high-level objects
The data structures and data stores
The reuse of standard components
o Memory management
Detailed-level design review:
Code reviews:
UNIT TESTING
A principal advantage of doing a unit test is that you can devise comprehensive tests for your program logic. In unit test, some topics to check for each function are
Check all paths and both sides of all branches.
Ensure that all instructions execute.
Verify operation at normal parameter values.
Verify operation at limit parameter values.
Verify operation outside of limit parameter values. Check the use of all called objects.
Check normal termination of all loops.
Check abnormal termination of all loops.
Check normal termination of all recursions.
Verify the handling of all error conditions.
Defect Prevention Strategies
DEFECT PREVENTION AT THE PERSONAL LEVEL
The approach to use in personal prevention work is much like that used by software teams in defect prevention reviews, as follows:
Select a specific defect type or class for analysis.
Summarize the causes of the defect. In team reviews, it is often helpful to use Ishikawa or fishbone diagrams.
Now that you understand the error that caused the defect, determine why you made it. One useful set of cause categories is communications, educa- tion, oversight, transcription, and process.
Devise ways to prevent the problem in the future.
Recycle through steps I through 4 until you run out of time or cease to have useful ideas.
Look for trends or patterns in your data that might suggest larg pervasive problems. An example might be a class of problem tha 31/37 trouble right after an extended period of nonprogramming work.
Analyze actions that have worked in the past and ensure you retain them and build on them.
Test your defect prevention ideas on at least one PSP-sized program and in- corporate those that work in a process update.
In devising such measures, first look for likely causes, such as the following:
Education
Communication
Oversight