1. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 1 CHAPTER 12 SOFTWARE QUALITY ENGINEERING & ASSURANCE NOTICE: This material is copyrighted and may be copied or downloaded ONCE ONLY by students who are registered in this course at Southern Methodist University or National Technological University.

2. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 2 Software Quality Engineering and Assurance References to text: Managing Quality16 Engineering Quality9,10 Software Testing11 Other Relevant Material8

3. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 3 SW Quality Assurance Typical Symptoms of a Problem We have a procedure to prevent that! Why did it happen? The procedure was not followed. Nobody even knew about it

4. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 4 Software Quality Assurance Symptoms of Another Problem They’ve violated company policy and we are facing a lawsuit! Did they know about the policy? Who authorized what they did?

5. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 5 Other Typical Symptoms of Quality Problems Management was surprised that the product did not work correctly after release – No one mentioned that it was not really ready The customers complain that the software does not work as advertised – But we tested it!

6. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 6 Motivation of the Software Developer Pride in Workmanship and Skill Fear of Failure Quality Software Software Developer

7. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 7 Software Quality Assurance Purposes: – To provide management and developers with visibility into the process being followed and the products being built So they can manage the outcome – To provide a quality control mechanism

8. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 8 Software Quality Assurance Typical Practices: – Reviews – Audits – Communication – Measurements – Independent confirmation of compliance Standards, requirements, procedures

9. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 9 What Is Software Quality?

10. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 10 There Are Many Definitions Crosby: Quality is Conformance to Requirements Juran: Quality is Fitness for Intended Use Webster: – (1) Quality is that which makes something what it is – (2) Quality is the Degree of Excellence Weinberg: Quality is value to someone

11. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 11 The Essential Characteristics The product does what it is supposed to do The customer gets what they paid for

12. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 12 External vs. Internal Quality External Quality: – Is determined by the factors whose presence or absence may be observed by the users – Is used as the ultimate criterion to judge the quality of a system Internal Quality: – Factors invisible to the end users – Help achieve the external quality

13. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 13 External Quality Factors Correctness – Does the system conform to its specs? Robustness – Does the software system react appropriately to abnormal conditions? Extendibility – Ease of adapting the software product to changes in its specifications

14. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 14 External Quality (continued) Compatibility – The ease with which the system can be combined with other systems Efficiency – The ability of the software to put as little demand on hardware as possible Portability – The ease of transferring software products to different hardware/software platforms

15. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 15 External Quality (continued) Functionality – The extent of possibilities supported by the software system Timeliness & Economy – The ability of the software to be cost effectively developed and released in a timely manner

16. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 16 External Quality (continued) Ease of use – The ease with which people with different backgrounds can learn to use the software and then effectively apply it to their benefit Verifiability – How easily and cost effectively can the correctness of the system be judged?

17. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 17 Internal Quality Factors Modularity – The degree to which elements of the software are independent from each other Readability – How hard is it to read and understand the source code? Reusability – The ability of the elements of the software to be used in later systems

18. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 18 Internal Quality Factors Some of the external quality factors have an equally strong impact on the internal quality – Timeliness & Economy – Compatibility – Portability – Extendibility

19. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 19 Evolution of Software Quality Quality Control Quality Assurance Quality Engineering

20. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 20 Quality Control Goal: Keep Quality at an Acceptable Level by Rejecting Unacceptable Products Requirements DevelopmentQC Inspection Pass Fail Standards of Quality Control Quality Assurance Quality Engineering

21. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 21 Problems with Quality Control Adversarial Relationship between QC and Developers No Motive to Improve Little Help with Improvement

22. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 22 Software Quality Control Criteria for QC Inspection – How many requirements are met? – How many tests have passed / failed? Problems (maybe) Unique to Software – Are the tests adequate? – Do the fixes inject more errors? – Developers may intentionally fail to test or avoid testing, to save time or because they are overconfident

23. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 23 Testing can detect the presence of errors, but not their absence DevelopTest ? Errors Injected Errors Reduced How Many Errors are Left?

24. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 24 Quality Assurance Goal: To assure that quality is achieved -- Add quality during development -- Improve processes, standards, and up- front evaluations of the product as it is being developed Quality Control Quality Assurance Quality Engineering

25. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 25 Quality Assurance Looks at the Entire Process Requirements DevelopmentQC Inspection Pass Fail Standards of Quality Process and Design Standards

26. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 26 Each Step of the Process Has an Effect on Final Defect Rate Process Step I = Defects Input O = Defects Output F = Defects Found and Fixed C = Defects Created O = I + C - F

27. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 27 Responsibilities of QA Review all development plans for completeness Participate as inspection moderators in design and code inspections Review a significant sample of all test results to determine adherence to standards Periodically audit SCM performance to determine adherence to standards

28. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 28 At Each Step, QA must... Inspect the product for – Conformance with standards – Satisfaction of requirements Evaluate the process for – Conformance with standards – Opportunities to improve – Process defects that may cause problems later on Evaluate the support processes as well

29. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 29 At Each Step, QA must... Monitor reviews, inspections, walkthroughs, etc. to see that they are accomplishing their objectives Trace back to prior steps when defects are found In addition to evaluating the development process, the QA procedures must also be tailored and revised for the needs of each new project

30. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 30 At the Requirements Analysis Step... Trace software requirements or specifications to original system or customer requirements Inspect or evaluate software requirements against standards to see that they are -- complete, -- correct, -- consistent, -- testable, and -- understandable “Clean Room” technique takes this farther PROGRAM SAMPLE (IN1,IN2) INTEGAR IN1,IN2,A,B,C; FOR I = 1 STEP 3 UNTIL 99 DO IF IN1 < A*B THEN IN2 := C + A*B ELSE IN2 := C + IN1 ENDIF ENDDO ** THE NEXT PART WILL SORT DO FOREVER Ii := I + 1 TEMP := ARRAY[I] - ARRAY[I+1] IF TEMP < 0, SWAP (ARRAY, i) ENDLOOP CALL CHECKORDER(ARRAY) ** NEXT WE DO THE i/o CALL PRINT(ARRAY) CALL DEBUG (ARRAY, I) CASE I OF CALL SUB1

31. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 31 “Clean Room” Software Development Technique Motive: Don’t let the Bugs Get In Method: Filter Them Out from the Beginning -- Define the requirements using a formal notation – reduces ambiguity – some consistency/correctness issues can be checked automatically -- Carry out rigid inspections Benefits: fewer problems later in the development process (e.g., reduced testing).

32. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 32 At the Design Step... Trace the design to the requirements specification (plus “derived requirements”) Evaluate the design against standards -- complexity -- cohesion -- understandability -- etc. Evaluation of design effectiveness, correctness, consistency, completeness Evaluate plans for testing and test cases

33. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 33 At the Coding Step... Trace code to design specifications Evaluate code against coding standards (example: give code to a new maintainer and see if she or he can understand it) Code walkthroughs or inspections to check on coding mistakes Test coverage analysis -- Do the tests address all requirements? (black box tests) -- Do the tests adequately evaluate the design and its implementation? (white box tests)

34. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 34 At the Module Testing Step... Test procedures and code analysis -- Evaluate test code like any other code -- Are the procedures documented? -- Are the expected results documented? Test results analysis -- Were the tests run? -- Were the results correct?

35. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 35 Two Philosophies of Testing Code Test a Little Review Thorough Test CodeReview Thorough Test

36. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 36 During Integration... Make sure that regression tests are performed -- Retest all modules potentially affected by any change Do independent tests -- Someone other than the person who developed the software Formal qualification tests (acceptance tests)

37. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 37 When do you Perform the Formal Qualification Test? Hardware Development Operating System Development Software Development System Integration System FQT Software FQT: Here or Here

38. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 38 Planning for QA Each development project should have a documented Software Quality Assurance Plan (SQAP) – May be part of SW Development Plan The SQAP documents tasks to be performed, standards of verification, procedures and organizational structure There is an IEEE standard for SQAPs

39. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 39 Pitfalls in implementing QA Lack of sufficiently skilled staff in QA – Software professionals are typically more interested in development jobs than QA QA management cannot effectively negotiate with the development team Senior Management commitment may fade under schedule pressures – The developers stop caring about QA & action revolves around insignificant issues

40. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 40 Pitfalls in implementing QA (Continued) QA organization operates without suitably documented and approved development standards and procedures Development team does not produce verifiable quality plans – Eventually results in a debate over which bugs are more important to fix rather than whether the product has sufficient quality or not

41. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 41 Pitfalls in implementing QA (continued) Disputes over who has responsibility for product quality and for performing QA functions – The software developers and managers are responsible for product quality – Quality assurance is a method to help them achieve quality through independent evaluation of their work (like a coach)

42. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 42 Reporting Chain for QA Staff Except in the highest maturity organizations, it is strongly recommended that the QA staff have a separate reporting chain from the project team – This improves their objectivity – And assures that disputes are resolved at a level in the organization that has responsibility for the possible consequences

43. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 43 Benefits Achieved by Quality Assurance over Quality Control Significant insight is gained into the process that can be used to gain long term benefits – Development can focus on specific weak points in the quality – Process improvements can be identified – Steps that are difficult to perform can be automated

44. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 44 Problems with Quality Assurance Can still be adversarial (although perhaps less than with quality control) Motivation to fix the process is still weak Can be more costly than quality control It can be hard to show benefits until long after the product has been shipped

45. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 45 Quality Engineering Goal: Build Quality In as Part of the Software Engineering Process A philosophical change that relies on the professional pride of the software engineer Engineering staff define and execute the quality assurance tasks Team approach to quality, with rewards based on quality Quality professionals are more like coaches and educators than evaluators Quality Control Quality Assurance Quality Engineering

46. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 46 Quality Engineering Focuses on People as well as Process Finding errors is good -- it keeps them from leaking through to the customer Problems result in process changes, not punishment of people Everyone appreciates that a competitive process is the way to remain a competitor Measurements are used so that decisions are based on fact (in addition to intuition) Independent tests are welcome -- they tell you if you are as good as you think you are

47. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 47 Peer Reviews Motivation: how to find problems in your work in a non-threatening way Method: evaluation of one individual’s work by others at the same organizational level (i.e., team members, not supervisors) Software DevelopersSoftware Managers

48. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 48 Peer Reviews - Cost Cost: may require 10-20% of the total development time -- this must be planned into the schedule -- it must also be planned into progress measures and reward systems

49. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 49 Peer Reviews - Benefits Benefits: reduced rework and faster development due to a more effective evaluation -- the peers understand the software best -- and they will not be as much of a threat when it comes to promotions and raises -- reciprocity -- you help them and they help you

50. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 50 Big Problem with Peer Reviews People don’t want to attend others’ peer reviews because they are behind in their own schedules Solutions? (class discussion)

51. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 51 Benefits of the Quality Engineering Approach Less adversarial Motivation and Information to improve Flexibility to change the process in response to a problem -- you understand the problem and its cause -- you understand the consequences of a change in the process Knowledge is the foundation of successful quality engineering

52. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 52 The Cost of Quality Engineering Your process may be more complex, costly and time consuming - at least when you start But you gain knowledge -- what and where to automate -- how and where to improve the process And you gain higher quality And you can begin to optimize the process, just as you optimize software

53. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 53 Cost of Quality Analysis

54. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 54 Quality (Fewer Defects; Customer Satisfaction) Productivity Cycle Time Customer Value Quality Improvements Cost Money How can we justify them?

55. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 55 Managers and Technical Staff must be convinced that Quality problems are serious Poor quality costs them money Quality is worth fixing Quality can be fixed by proper techniques In Order to Justify Quality Improvements...

56. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 56 The Fundamental Prejudice Quality improvement is a non-value- added activity – It costs overhead resources – The benefits are not necessarily real So we seek to avoid it Cost of Quality (COQ) Analysis is used to address this prejudice

57. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 57 The First Question “What does it cost to have quality?” This is what management and technical staff will typically ask when approached with a proposal to improve quality

58. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 58 The Right Questions “What is the Return on Investment for Improved Quality?” “What is the Payoff?”

59. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 59 Categorizing Quality-Related Costs Quality Related Costs Cost of Conformance Cost of Non- Conformance Prevention Costs Appraisal Costs Failure Costs

60. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 60 Cost of Conformance Things that improve quality – Prevention costs - prevent poor quality Predictive metrics, training, root cause analysis, process improvement – Appraisal costs - detect poor quality Tests, inspections, audits

61. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 61 Cost of Non-Conformance The price you pay when you fail to achieve quality – Internal failures Costs incurred before product shipment – External Failures Costs incurred after product shipment

62. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 62 Effects of Maturity on Costs SEI Maturity Level Cost as a Percent of Development Cost 10 20 30 40 50 60 1 2 34 5 Prevention Appraisal Internal Failures External Failures Total COQ As reported by Knox (see references)

63. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 63 Summary Quality Control focuses on the end product Quality Assurance focuses on the process Quality Engineering focuses on process and people, integrating QA with the software engineering process

64. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 64 References Knox, 1993, Raytheon studies reported by Houston and Keats, Software Quality Matters, vol 5, no 1 (Spring, 1997), U. of Texas SW Quality Institute Musa, John D, 1992, “The Operational Profile,” in Software Reliability Engineering: An overview. Weinberg, Gerald M., 1992, Quality Software Management, Volume 1, Systems Thinking, Dorset House, New York, ISBN 0-932633-22-6.

65. January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 65 End of CHAPTER 12