Please enable JavaScript.
Coggle requires JavaScript to display documents.
SOFTWARE QUALITY MANAGEMENT, Paul Jiménez Vela | 24400238 | Ingeniería de…
SOFTWARE QUALITY MANAGEMENT
The PSP strategy focuses on managing the defects in the software you produce. By improving your defect management, you will produce more consistently reliable components.
These components, in turn, can then be combined into progressively higher quality systems.
While the quality benefits of this strategy are important, the productivity benefits are even more significant.
Software quality can be viewed as an economics issue.
You can always run another test or do another inspection.
In large systems, every new test generally exposes a host of new defects.
Quality software was previously defined as software that meets users’ needs. A similar definition applies to the software process.
The definition of a quality PSP is thus a PSP that meets your need to efficiently produce quality products.
Some process requirements are fairly obvious and some are not.
The most obvious requirement is that process consistently produces quality software. The list of process requirements can be expanded almost indefinitely.
The principal focus of any software quality definition should be the users’ needs.
When the quality of the parts of a software system is poor, the development process becomes fixated on finding and fixing defects.
The magnitude of this fix process is often a surprise. As a result, the entire project becomes so preoccupied with defect repair that more important user concerns are ignored.
When a project is struggling to fix defect in system test, it is usually in schedule trouble as well.
In a board sense, the users’ views of quality must deal with the product’s ease of installation, operational efficiency, and convenience
The economics of software quality largely concern the costs of defect detection, prevention and removal.
The costs 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 going 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 fic to ensure it doesn’t cause another problems
Changing the documentation as needed to reflect the fix
While the fix time can often be longer for design defects and much longer for requirement defects, the times to identify the defects appear to be the same.
The basic problem is the number of defects in the product at the start of test.
While they could either test for another year or ship a poor quality product sooner, the most economical answer is for the software engineers to so manage the quality of their personal processes that they remove most of the defects before test.
Juran describes the cost of quality measure as a way to “quantify the size of the quality problem in language that will have impact on upper management.”
The definitions of cost-of-quality components are the following:
Failure costs: the costs of diagnosing a failure, making necessary repairs, and getting back to into operation.
Appraisal costs: the costs of evaluating the product to determine its quality level.
Prevention costs: the costs associated with identifying the causes of the defects and the actions taken to prevent them in the future.
Juran categorizes design reviews as prevention costs. Prototypes are typically developed to build a clear understanding of some requirement, function, or software structure.
As you develop a strategy for improving the quality of your programs, you should consider the following issues:
Determine the quality methods that are most effective for you
Periodically reevaluate your strategy and set new goals
Decide how to measure your process
It is important to distinguish between measures of product quality and measures of process quality.
The quality of the finished product is one important measure of process quality.
You should also be careful in using productivity measures because they can easily be misused.
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.
The problems with this method suggest a third way to select a quality strategy, that of focusing on the causes of the errors that produced the defects.
Your process improvement strategy must be dynamic. What is right for you today will not likely be best forever.
Not only will you develop new skills, but also the technology will change, you will have a different working environment, and you will be faced with different problems.
Various benchmarks techniques can be helpful in tracking processes and comparing them with similar processes used by other individuals, groups, or organizations.
A useful general-purpose process benchmark should do the following:
Measure the ability of the process to produce high-quality products
Provide a clear ordering process performance from best to worst
Indicate the ability of the process to withstand perturbations or disruptions
Provide required data that is objectively measurable
Provide data in a timely manner
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 didn’t 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
Your principal guide in selecting review areas for focus should be your own defects data.
During each review, however, you should consider the following topics
Detailed level design reviews
Code reviews.
High level design reviews
It is most desirable to find and fix all defects before you begin testing; however, this is rarely possible.
Reviews and inspections are performed by people, and people are error prone.
If you’re not sure where to start with defect prevention, examine those defects that caused the most trouble in system test or use.
You could establish a special item in your coding standard to require initialization of every variable when it is declared.
Detecting and fixing defects is critically important, yet it is inherently defensive strategy.
You need to find something you can be reasonably confident you will always do.
To make significant quality improvements, you should identify the causes of your defects and take steps to eliminate them.
Paul Jiménez Vela | 24400238 | Ingeniería de Software