Week 8 - Quality Management Learning Objectives You should be able to: §List and explain common principles of quality management (QM) §List, distinguish between, and describe the processes and tools of Quality Planning, Assurance, and Control §Apply QM principles to Project Management §Apply QM principles to software development project management §Demonstrate how the CMM incorporates QM principles

Quality: §is everyone’s job, §comes from prevention not inspection, §means meeting the needs of customers, §demands teamwork, §requires continuous improvement, §involves strategic planning, §means results, §requires clear measures of success.

History of QM/QC/QA §Deming: plan, do, check, act §Juran: improvement, planning, control §Crosby: zero defects, management commitment §Ishikawa l quality circles, root cause of problems §Taguchi: prevention vs. inspection §Feigenbaum: worker responsibility

Quality Management §Organization-wide commitment: culture §Results and measurement focus §Tools and technical support needed §Training and learning §Continuous improvement of each process l Is it necessary? l Can it be done better?

7 Malcolm Baldrige Award Categories Pre-production l leadership l information and analysis l strategic quality planning Production l human resource allocation l quality assurance Post-production l quality results l customer satisfaction

ISO 9000 Standard: 5 Elements (500 points) §Quality Planning §Performance Information §Cost of Quality (economics) §Continuous Improvement §Customer Satisfaction

Quality in Project Management I §ISO 9000, TQM, CQI principles §Prevention over inspection l lower cost, higher productivity, more cust. satisfaction §Management responsibility and team participation §Plan-do-check-act (re: Deming, etc.) - PDCA §Applied successfully in environments that have well-defined processes and products §More difficult in areas like software development

Quality in Project Management II §Customer satisfaction l validation: “the right job done” §Conformance to specifications l verification: “the job done right” §Fitness for use l can be used as intended §Satisfaction of implied or stated needs l All project stakeholders considered l Project Management: making implicit needs explicit §Project Processes and Product l continuous improvement of both

Quality Planning Quality Assurance Quality Control Project Scope Quality Standards Quality Policy Checklists Product Description Operational Definitions Quality Management Plan Work Results Quality Improvement Actions

Quality Planning (QP) §Identifying relevant quality standards §Determining how to meet them §QP inputs: l quality policy: adopted, disseminated l scope and product description l standards, regulations

Software Quality Planning §Functionality l features: required and optional §Outputs §Performance l volume of data, number of users l response time, growth rate §Reliability: MTBF (mean time between failures) §Maintainability

QP Outputs §Quality management plan l how team will implement quality policy l structure, responsibilities, resources, processes l (same as project plan?) §Operational definitions l metrics: what it is and how it’s measured §Checklists l industry-specific

Quality Assurance (QA) §Evaluating project performance regularly to assure progress towards meeting standards §Inputs: l quality management plan l operational definitions l results of measurements §Outputs: l quality improvement actions §Tools: QP tools, quality audits

QP/QA Tools §Cost / benefit analysis and tradeoffs l less rework = higher productivity, lower costs, stakeholder satisfaction §Design of Experiments l comparison of options, approaches §Benchmarking l comparison of project practices to best practices §Cause and effect (fishbone, etc., diagrams)

Quality Control (QC) §Monitoring project results §Measuring compliance with standards §Determining causes if not in compliance §Identifying ways to eliminate causes §Performed throughout project life cycle

QC Inputs and Outputs Inputs: §Work results §Quality Management Plan §Operational Definitions §Checklists Outputs: §Quality Improvement §Acceptance decisions §Rework §Process adjustments l corrective or preventive actions §Completed checklists l project records

QC Tools §Inspection: l measuring, examining, testing products §Control Charts: l monitor output variables l detect instability in process l graphical display of results §Pareto analysis l 80 / 20 rule l histogram: frequencies §Statistical sampling l acceptable deviation l 6-sigma l 7-run rule

Statistical Quality Control §Prevention l keeping errors out of the process §Inspection l keeping defects from the customer §Sampling: attributes and variables §Tolerances: acceptable ranges §Control limits: acceptable levels

Testing (Software) §During most phases of product development §Unit tests §Integration testing §System testing §User acceptance testing

Improving Software Quality §Leadership l top management and organization-wide commitment to quality §Costs of quality l cost of non-conformance l costs: prevention, appraisal, failures, testing §Work environment

PMI Maturity Model: 5 levels §Ad-hoc: chaotic, chronic cost & schedule delays §Abbreviated: processes in place, but not predictable §Organized: documented, standards that are used §Managed: measures are collected §Adaptive: l feedback enables continuous improvement l project success is norm

Capability Maturity Model (CMM) - 5 levels 1. Initial: chaotic, heroic efforts, unpredictable 2. Repeatable: processes & standards established 3. Defined: documented standards, training, use 4. Managed: quantitative measures, predictable 5. Optimizing: defect-prevention, organization- wide continuous improvement

CMM and Quality (see Appendix A: goals for key process areas) Level 2: §requirements management (customer focus) §project planning (quality planning) §project tracking and oversight (quality control) §software quality assurance §configuration management (prevention)

CMM Level 3 and Quality §organization process focus (commitment) §organization process definition (operational definitions) §training program §software product engineering (prevention) §intergroup organization (teamwork) §peer reviews (teamwork)

CMM Level 4 and Quality §Quantitative process improvement §Software quality management goals l planned and measured CMM Level 5 and Quality §Defect Prevention (prevention) §Technology and Process Change Management (continuous improvement)

Achieving Software Quality §Focus on critical requirements early §Use metrics early and continuously §Provide development tools supporting: l configuration control, change control l test automation, self-documentation l abstraction, reliability, reuse §Early and continuous demonstration-based evaluations §Major milestone demonstrations assessed against critical requirements

Software Quality Measurement §Software quality measured by ease of change §Examples of data collected: l Number and types of changes l number of components / effort (FPs, SLOC, classes...) l number of change orders (SCOs) l number of defective and fixed components §Baseline: total size (SLOC, FP, classes, etc.) §Scrap: broken code, may or may not be fixed §Rework: healthy early in project, should decrease

SCO: Software Change Order 1. rework a poor quality component (fix) 2. rework to improve quality (enhancement) 3. accommodate new customer requirement (scope change) Configured Baseline: l the set of products subject to change control l size of “completed” components

Software Quality Metrics §Modularity: l breakage localization: extent of change re: baseline size §Adaptability l cost of change (effort needed to resolve and retest) §Maturity l number of SCO’s over time = MTBF during testing §Each of above 3 should decrease over time §Maintainability l productivity of rework / productivity of development

Operational Definitions §Defects: measured by change orders SCOs §Open rework (breakage) l broken components measured by SCOs §Closed rework (fixes) l fixed SCOs §Rework effort: effort expended fixing SCOs §Usage time: baseline testing in normal use

Quantifying Quality Metrics §Modularity: l breakage / SCOs §Adaptability l rework effort / SCOs §Maturity l usage time / SCOs (mean time between defects) §Maintainability l (percent broken) / (percent rework vs. total effort) §End-product and “over time” indicators

Peer inspections: pros and cons Pros §Team development §Accountability §Determine causes of defects §20%: critical components Cons §Superficial §Not cost effective §Other QA activities are more effective