Software Quality Engineering CS- 449

1. Software Quality EngineeringCS- 449 Lecture # 2

2. Software Quality Engineering • The function of software quality that assures that quality is built-in to the software by performing analysis and investigations on the requirements, design, code and verification processes and results to assure that reliability, maintainability, and other quality factors are met.

3. Hierarchy

4. SQE tasks • Quality planning • Execution of selected QA activities • Measurement and analysis

5. Why Software Quality? • Reduces time to market for new products • Enhances market share compared to direct competitors • Minimizes “scrap and rework” expenses • Attracts and keeps “top-gun” personnel • Minimizes the risk of serious litigation • Minimizes the risk of serious operating failures and delays • Minimizes the risk of bankruptcy or business failures, which may be attributed directly to poor quality or poor software quality • Enhances return on investment

6. Objective Quality vs Perceived Quality • Quality might be the most important factor underlying the long-term success of products and firms. The business press routinely cites quality as the cause of firm success and failure. • Objective quality is operationalized as a composite of instrument measures and expert ratings on multiple product attributes. For example, a personal computer’s objective quality attributes include processing speed, hard disk capacity and features like the modem. Objective quality does not include intangible attributes like aesthetics and brand image or sales person behavior. • Perceived quality is the overall subjective judgment of quality relative to the expectation of quality. These expectations are based on one’s own and others’ experiences, and on sources including brand reputation, price, and advertising. It is not necessary to use or examine a product to form perceptions of quality.

7. Objective Quality vs Perceived Quality • However, it is now well established that it is not the objective quality but rather customers’ perceptions of quality that drive preferences and, ultimately, satisfaction, loyalty, sales, and profitability. • Numerous anecdotes suggest that customer perceptions of quality do not reflect objective quality. Companies frequently find that negative perceptions persist even after products perform well in quality tests. For example it took Google three years after its launch to be perceived as the superior search engine.

8. How does the Objective Quality affects Perceived Quality? • DebanjanMitra and Peter N. Golder examine the relationship between objective and perceived quality for 241 products in 46 product categories over a period of 12 years. • On average, they found that the effect of a change in objective quality is not fully reflected in customer perceptions of quality until after about six years. • In the first year after a quality change, only about 20% of the total effect over time is realized. These effects are significantly larger and quicker for a decrease in quality relative to an equivalent increase. • Interestingly, their study suggested that brand reputation has a “double” advantage. High-reputation brands are rewarded three years quicker for an increase in quality and punished one year slower for a decrease in quality compared to low-reputation brands.

9. Role of Customers • “Your customers are in a perfect position to tell you about quality, because that’s all they’re really buying. They’re not buying a product. They’re buying your assurances that their expectations for that product will be met. • And you haven’t really got anything else to sell them but those assurances. You haven’t really got anything to sell but quality.” [I know it when I see it, Guaspari 1985] • Quality is customer driven • Begins with customers • Ends with customers • Stretches beyond stated requirements

10. Meeting People Quality Expectations • Software systems must do what they are supposed to do. • Focus: Requirements validation • Example: An airline reservation system is supposed to handle reservations, not intended to fly airplanes automatically.

11. Meeting People Quality Expectations • Software systems must perform the specific tasks correctly or satisfactorily. • Focus: Requirements Verification • Example: In the airline reservation system example, the system should help travel agents or individual travelers make valid reservations within a pre-specified time limit, instead of making invalid ones.

12. Verification and Validation Verification Validation A dynamic mechanism of validating and testing the actual product Always involves executing the code. It is a computer based execution of the program Uses methods like black box testing, gray box testing and white box testing. Checks whether the software meets the customer’s expectations and requirements. • A static practice of verifying documents, design, code and program • Does not involve executing the code • Human based checking of documents and files • Uses methods like inspection, review, walkthrough, and desk checking etc. • Checks whether the software conforms to the specification

13. Verification and Validation Verification Validation A high level exercise. Can catch errors that verification cannot. Target is actual product – a unit, a module, a bent of integrated modules, and effective final product. Carried out with the involvement of testing team Generally follows after verification. • A low level exercise. Can catch errors that validation cannot. • Target is requirement specification, application and software architecture, high level, complete design, and database design etc. • Done by QA team to ensure that the software is as per the specifications in the SRS document • Generally comes first-done before validation

14. Verification and Validation • Suppose we have the specifications related to the project than by checking that specifications without executing to see whether the specifications are up to the mark or not is what we have done in verification. • Similarly Validation of the software is done to make sure that the software always meets the requirements of the customer by executing the specifications of the project and product.

15. Quality attributes • Small q: Intrinsic product quality • Big Q: Extrinsic product quality

16. Quality attributes • Product-Specific Attributes • Ease of Use • Documentation • Defect Tolerance • Defect Frequency • Defect Impact • Packaging • Price versus Reliability • Performance

17. Quality attributes • Organization-Specific Attributes • Service and Support • Internal Processes

18. References • Software engineering: A practitioner’s approach by Roger S. Pressman 8th edition • Metrics and models in software quality engineering by Stephen H. Kan 2nd edition