Project Quality Management QA and QC Tools Techniques

Project Quality Management QA and QC Tools & Techniques Lec#10 Ghazala Amin 1

The Seven QC Tools Identification Data Tables Pareto Analysis Cause and Effect Analysis Trend Analysis Histograms Scatter Diagrams Control Charts 2

Tools of TQM • Tools for generating ideas – Check sheet/Data Table – Scatter diagram – Cause and effect diagram • Tools to organize data – Pareto charts – Process charts (Flow diagrams) • Tools for identifying problems – Histograms – Statistical process control chart 3

Data Table Defects Proces s. A s. B Proces s. C s. D Total Incorrect Invoice 4 1 - 2 7 Incorrect Inventory 5 2 1 1 9 Damaged Material 3 2 3 8 Incorrect Test doc. 1 3 4 2 10 Total 13 6 7 8 34 4

Cause and Effect - Fishbone Chart Cause Time Machine Method Effect Material Major Defect Energy Measure People Environ. » Identify major and minor causes for the defect » Classify in related groups » Visualize the group with the most causes 5

Sample Fishbone or Ishikawa Diagram 6

Scatter Diagram Y X Plot the results of two variables. Used to determine the relationship between two or more pieces of corresponding data. The data are plotted on an “X-Y” chart to determine correlation » Show distribution around Central tendency » Highlight Exceptions (out of tolerance condition) » Source of data for the Pareto Chart 7

Pareto Analysis - Definition • Pareto Diagram - A histogram ordered by frequency of occurrence that shows how many results were generated by each identified cause. • Pareto Law - A supposition that states that a relatively small number of causes will typically produce a large majority of the problems or defects. • Commonly referred to as the 80/20 principle in which 80% of the problems can be attributed to 20% of the causes. 8

Pareto Analysis • Pareto analysis involves identifying the vital few contributors that account for the most quality problems in a system. • Also called the 80 -20 rule, meaning that 80 percent of problems are often due to 20 percent of the causes. • Pareto diagrams are histograms, or column charts representing a frequency distribution, that help identify and prioritize problem areas. 9

Pareto Diagram Primary Purpose: Focus improvement efforts on the most important causes 15 10 5 0 Noise Wobble Pressure Other Pareto's rule: A large number of defects are the result of a small number of causes. Fix the problems that are causing the greatest number of defects first. Does not account for severity of the defects 10

Sample Pareto Diagram 11 Ranks defects in order of frequency of occurrence to depict 100% of the defects.

Acceptance Sampling • Used when expensive and time-consuming to test 100%. • Random sampling may be used to check the characteristics and attributes of a given lot of goods. • Determines whether or not the lot conforms to the specifications or standards necessary to support the overall project requirements. • Inspection and test standards must be established to ensure that procedures are adequate to determine whether a lot is conforming or nonconforming to specifications. • Important to select a sample size that will provide sufficient information about the larger lot of goods without costing a great deal of money. • Must determine in advance the number of allowable defects before the lot is rejected. 12

Statistical Sampling • Statistical sampling involves choosing part of a population of interest for inspection. • The size of a sample depends on how representative you want the sample to be. • Be sure to consult with an expert when using statistical analysis. • Example: QA team randomly selected 8 drawings from 80 engineering drawings generated during the planning and design phase for inspection. This exercise of random selection is Statistical sampling. 13

Statistical Sampling » Prevention � Keep Errors out of production � Keep defects from reaching customers » Attribute Sampling � Conformance or non-conformance 14

Statistical Sampling » Common Vs. Special Causes � Common -- Normal process variation � Special -- Unusual events » Tolerances � Acceptance range (product is acceptable or not) � Control limits (process is in or out of control) 15

Quality Control Charts • Control Charts - A graphic display of the results, over time and against established control limits, of a process. • The charts are used to determine if the process is in control or in need of adjustment. 16

Quality Control Charts • A control chart is a graphic display of data that illustrates the results of a process over time. • The main use of control charts is to prevent defects, rather than to detect or reject them. • Quality control charts allow you to determine whether a process is in control or out of control. – When a process is in control, any variations in the results of the process are created by random events; processes that are in control do not need to be adjusted. – When a process is out of control, variations in the results of the process are caused by non-random events; you need to identify the causes of those non-random events and adjust the process 17 to correct or eliminate them.

Control Chart Upper Specification Limit Upper Control Limit Mean Lower Control Limit Lower Specification Limit 10 8 6 4 2 0 -2 -4 -6 -8 -10 Number of defects - Process “A” - Time » Process results over time » Process is in control when the number of defects fall within upper and lower control limits. » Process adjustments are immediate corrective actions based on QC measure. » Process can be improved to meet tighter control limits: Processes in control should not be adjusted. 18

Quality Control Charts and the Seven Rule • The seven rule states that if seven data points in a row are all below the mean, above the mean, or are all increasing or decreasing, then the process needs to be examined for non-random problems. • You can use quality control charts and the seven rule to look for patterns in data. A control chart helps prevent defects and allows you to determine whether a process is in control or out of control 19

Sample Quality Control Chart 20

Out of Control States • Visual patterns indicating out-of-control state or a condition that requires attention: • Outliers: a sample point outside the control limits (also referred to as out -of-control) • Hugging control limit: a series (run) of points that are close to a control limit. Requires correction to prevent data points from going outside the control limit. – Rule of Thumb: Considered abnormal if two of three, three of seven, or four of ten data points fall within the outer one-third of the chart. • Cycle: A repeating pattern of points. 21

Out of Control States • Visual patterns indicating out-of-control state or a condition that requires attention: • Trend: A series of consecutive points which reflect a steadily increasing or decreasing pattern. – Rule of Thumb: Considered abnormal when seven or more consecutive data points reflect a steadily increasing or decreasing pattern. • Run: A series of 7 or more consecutive points (observations) fall on the same side of the average (mean) – Rule of Thumb: Considered abnormal if seven consecutive points, ten of eleven, or twelve of fourteen data points are above or below the process average. 22

Quality Testing in IT World • Many IT professionals think of testing as a stage that comes near the end of IT product development. • Testing should be done during almost every phase of the IT product development life cycle. 23

Testing Tasks in the Software Development Life Cycle 24

Types of Tests • Unit testing tests each individual component (often a program) to ensure it is as defect-free as possible. • Integration testing occurs between unit and system testing to test functionally grouped components. • System testing tests the entire system as one entity. • User acceptance testing is an independent test performed by end users prior to accepting the delivered system. 25

Figure. Gantt Chart for Building Testing into a Systems Development Project Plan 26

Testing Alone Is Not Enough • Watts S. Humphrey, a renowned expert on software quality, defines a software defect as anything that must be changed before delivery of the program. • Testing does not sufficiently prevent software defects because: – The number of ways to test a complex system is huge. – Users will continue to invent new ways to use a system that its developers never considered. • Humphrey suggests that people rethink the software development process to provide no potential defects when you enter system testing; developers must be responsible for providing error-free code at each stage of testing. 27