Download presentation
Presentation is loading. Please wait.
Published byEdmund Barnett Modified over 9 years ago
1
Software Quality Chapter 20-21
2
Software Quality How can you tell if software has high quality? How can we measure the quality of software? How can we make sure software has high quality?
3
Perspective on quality Customer system not crashes system follows documentation system is logical and easy to use Developer system is easy to change system is easy to understand system is pleasant to work on
4
Characteristics of Software Quality Some external characteristics that the user is aware of: Correctness Usability Efficiency Reliability integrity extent to which it allows unauthorized access to data Adaptability Accuracy Robustness
5
Characteristics of Software Quality Some internal characteristics of software that are code- centered: Maintainability Flexibility Portability Reusability Readability Testability Understandability
6
Total Quality Management Factories Goal is for every item coming off the assembly line to be perfect Management, production, engineering, QA Everyone is involved in quality Develop a reliable, repeatable process Continuously improve the process
7
Failure vs. flaw Failure - program didn’t work right Flaw - mistake in the text of the program Failure analysis - what flaw caused this failure? Flaw analysis - what is wrong with our process that allowed this flaw to be created and not detected?
8
Failure costs Internal rework repair failure analysis External resolving complaints returning and replacing product help line
9
Prevention costs Prevention planning managing and collecting information reviews Appraisal inspection Testing
10
Cost of fixing an error DesignCodeDev. Test System Test Field operation 3-6 times Req. 10 times 15-40 times 30-70 times 40-1000 times 10 1 time 100 1000 1
11
Johnson’s Law If you don’t test for it, your system doesn’t have it. Is it easy to use? Easy to maintain? Does it crash? Does it match the documentation? Does it make customers happy?
12
Ways not to improve quality Say “Be more careful!” Say “Quality is important.” Find out whose fault it is and fire him.
13
How to improve quality Measure and compare Determine root cause of problems Create ways to eliminate problems
14
If you don’t see it, it doesn’t exist Measure quality over time (metrics) Display in a public place Make quality goals, then check to see if you meet them.
15
How to appraise quality Requirements reviews by customers prototyping Analysis and design models formal reviews, inspections Current system bug reports user tests surveys
16
Bug tracking Keep track of who reported the bug (the failure) description of the failure severity the flaw that caused this failure who is repairing it the repair
17
Bug tracking Use information about failures to estimate reliability Compare critical nature of failure iteration failure discovered module that had the flaw
18
Use quality information to make decisions “Must repair all level 1 failures before shipping” “Half of all level 1 and 2 failures in the alpha release were in the Call Processing module; we should rewrite it.” “Half of all level 1 and 2 defects found in the design reviews were in Call Processing; we should rewrite it.”
19
Bug tracking Discover the flaw (defect) that caused each bug Categorize flaws Look at categories with the most flaws and improve your process to eliminate them.
20
SQA Manager Responsible for SQA policy Develops testing plan Checks that plan is being followed Develops review process Trains reviewers Monitors reviews Develops customer survey plan …
21
Technical Reviews A way to evaluate the quality of requirements, designs, and software A way to improve the quality of requirements, designs, and software A way to educate new developers and ensure that developers are consistent Proven to be cost-effective!
22
Main goal: evaluate quality Produce a report describing potential problems summary of overall quality pass/fail Evaluated by expert outsiders must know enough shouldn’t know too much
23
Secondary goal: improve quality Find flaws Enforce standards Improve standards Provide feedback to management
24
Review methods The most important step to improve the software engineering performance Various review methods Inspection Walk-throughs Personal reviews
25
Inspections A structured procedure for the team review of a software product Has a formal structure, and each participant has a defined role Typical inspection process Preparation Inspection meeting Repair and report To be more effective, inspections are measured, a report is produced, and the action items are tracked to closure.
26
Walk-Throughs A less formal process that usually follows a presentation format A developer walks through how the program performs, while the audience raises issues and asks questions. Generally lack of advance preparation or follow-up
27
Personal Reviews You examine your own products. To find and fix as many defects as possible before implementing, inspecting, compiling, or testing the program As the PSP data will show, a little time spent on reviewing code can save the much longer amount of time that would be spent on debugging and fixing during compile and test.
28
Code Reviews are More Efficient than Testing (1) In reviews, you find the defects directly. When you review a program, you know where you are and the results its logic is supposed to produce. You establish logical relationships and construct a mental context of the program’s behavior. In testing, you get only symptoms. You start with some unexpected system behavior. You then spend a lot of time figuring out what caused those symptoms, i.e. debugging.
29
Code Reviews are More Efficient than Testing (2) A debugger's principal advantage is that it helps you to step through the program logic and check the important parameter values. This process is effective only if you know what the parameter values are supposed to be.
30
Review Principles Establish defined review goals. Follow a defined review process. Measure and improve your review process.
31
Establish Review Goals To find and fix all defects before the first compile or test When engineers start doing reviews, they find only about 1/3 to 1/2 of defects. By analyzing the data on reviews and making appropriate changes in review process, the rate can be improved significantly. With care can practice, some find they can reach 80%, or even 95%.
32
Follow a Defined Review Process Code review script Code review guideline and checklist (C++)
37
Measure and Improve Your Review Process To improve review quality Generally, a high-quality review is one that finds the greatest number of defects in the least amount of time. Need to measure the time spent on review, and track all defects found in review and later
38
Review Measures
39
Who founds more defects?
40
Review Measures Four explicit review measures The size of the program being reviewed LOC If no code available, use text lines or pages of design, or estimated LOC. The review time in minutes The number of defects found The number of defects in the program that were later found these are called escapes
41
Derived Review Measures Several measures can be derived from the basic measures. The review yield the percentage of defects in the program that were found during the review The defect found per KLOC of design or code reviewed The defects found per hour of review time The LOC reviewed per hour Defect removal leverage (DRL), or the relative rate of defect removal for any two process phases
42
Review Yield Yield Cannot be precisely calculated until the reviewed has been extensively tested and used Still able to make useful early approximations; upper bound A high yield would be good and a low yield poor.
44
Result of review Review summary who, what, when and the conclusion Issues list Can result in more detailed reports Give priority to issues Can be disagreement on issues Most issues are about product, but can also be about process or standards
45
In real life Usually there are several meetings until all issues are resolved Project has a policy that determines what would be reviewed “Passing review” is a measure of progress Reviews improve checklists, not just the product under review
46
Summary Reviews are a key quality control technique Use reviews to improve your process, not just your product
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.