IT Quality

Welingkar
 Course Content
– Introduction to Quality
– Concepts
• Quality Assurance and Quality
Control
• Cost of Quality
• Acceptable Quality Limit
• Quality Management System
– Quality Management
– Implementing SQA
– Implementing Metrics Program
– Defect Prevention
– Testing
– Quality Models
• ISO
• CMMi
2
What is Software Quality?

3
 What do Quality Gurus say
Achieving high levels of
user satisfaction, Conformance to user
portability, maintainability, requirements – Phil
robustness and fitness for Crosby
use – Dr Barry Boehm High levels of user
satisfaction and low
defect levels often
Being on time, associated with low
within budget and complexity – Tom
meeting user needs McCabe
– James Martin

Achieving excellent levels

of fitness for use,
conformance to
Striving for excellence
requirements, reliability
– Edward Deming
and ‘maintaintability’ –
4
Watts Humphrey
Aspects of Quality

5
 User Perspectives
• Who are the users and what is important to them?
• How do they prioritize their requirements?
• How do the requirements affect the way we build, package, install and
support the software?
• Is the product convenient? Can the users remember how to use it? Can
they easily find out what they do not know?
• Is the product responsive? Does it surprise the users?
• Does the product protect them from others? From themselves? Does it
insulate them from the system’s operational mechanics?
• Is the documentation understandable?
• Is the design suitable for future enhancements?

6
 Changing View of Quality
• Responsibility of workers
• Hide defects
• Faulty justification, excuses
• Minimum documentation
• Increase project costs
• Internally focused
• Close supervision
• During project execution
• Responsibility of everyone
• Highlight defects
• Cooperative solutions
• Document ‘lessons learnt’
• Saves money
• Customer focused
• Self discipline
• Plan for entire project
7
Quality Assurance and Control

8
Quality Assurance and Control

QA
or
QC

9
Quality Assurance and Control

10
Cost of Quality

11
 Cost of Appraisal (CoA)
• Detection Cost
• Quality Control
• Cost of Conformance
• Includes time / costs for
– Reviews
– SW Testing
– Preparation
– Execution
 Cost of Prevention (CoP)
• Quality Assurance
• Cost of Conformance
• Includes time spent / cost s for
– Process definition and deployment
– Process improvement
– Training
– Measurements
– Process audits
 Cost of Failure (CoF)
• Cost of Non Conformance
• Includes time spent / cost s for
– Rework
– Service calls
– Scrap
– Product liability
• May be many others, some very
high
Cost of Quality

COP,
COA
or
COF
15
Cost of Quality

16
 Cost of Poor Quality

Tip of the
Iceberg

17
Cost of Correction

18
Introduction vs Detection

19
Using Quality Costs

20
 Software Engineering Axioms
• Adding developers to a project will likely result in further
delays and accumulated costs
• Basic tension of software engineering
– better, cheaper, faster — pick any two!
– functionality, scalability, performance — pick any two!
• The longer a fault exists in software
– the more costly it is to detect and correct
– the less likely it is to be properly corrected
• Up to 70% of all faults detected in large-scale software
projects are introduced in requirements and design
– detecting the causes of those faults early may reduce their
resulting costs by a factor of 100 or more

21
Quality Management

22
Organization Structure

23
Quality Management System

24
 What is the difference between standards and guidelines?
 Users of QMS
• Project Manager
– Risk management
– Status reporting
– Report collation
– Estimation
– Collection and Analysis of Data
– Project Planning Template
– Best Practices & Lessons Learnt

• Programmer/ Developer
– Coding Standards
– Storage of Test Data & Test Results (verification & changes)
– Project Repository & CM

25
 Users of QMS
• System Designer
– Process and Data Architecture
– Standards for Maintainability (high cohesion and low coupling)
– Requirements Specification: no ambiguities and contradictions

• Analyst
– Requirement Specification: close organization of related functions
– Checklist
– Interface of Requirement Specification with customer requirement

• Tester
– SRS  Test cases
– Storage of test data and outcomes: reuse
– Environment for system integration

26
 Users of QMS
• Senior Management
– Target vs Achievement
– Audit Trails
– Defects Data
• Staffing Function
– Skill level, required training
– Project completion: Update resume,
Performance rating

27
 Users of QMS
• Marketing
– Estimates: lessons learnt, best practices,
reuse
• Customer
– Milestone review
– Controls
– Reporting format

28
 Quality Plan
• Completeness
• Accessibility – in the proper format, where
u can find it
• Clarity – Usage
• Specifics – what, who, when, what cost
• Precision
• Accuracy

29
 QMS Development
• Identify processes and their application throughout the
organization
• Determine sequence and interaction of these processes
• Determine criteria and methods needed to ensure that
operation and control of the processes are effective
• Ensure availability of resources and information
necessary to support the operation and monitoring of
these processes
• Monitor, measure and analyze processes
• Implement action necessary to achieve planned results
and continuous improvement of the processes
30
Process Improvement

31
32
Process Improvement Process

33
 Sw Process Measurements
• What Cannot improve
• Why what you do not measure
• How
• Identify measures
• Who
• Collect and collate
• Where • Analyze and consolidate
• When • Isolate problem areas and causal
Analysis

34
 Defect Prevention
Project end
Reports
Metrics Analysis Identify Prioritize
Defects Defects
Audit & Assessment
Reports
Preventive Root
Action with Cause
Goal Analysis

Monitor
Effectiveness
35
 Quality Tools
• 7 BASIC TOOLS
– Flowchart: Helps in analyzing a process
– Cause-and-effect diagram (also called Ishikawa or fishbone chart): Identifies
many possible causes for an effect or problem and sorts ideas into useful
categories
– Check sheet: A structured, prepared form for collecting and analyzing data; a
generic tool that can be adapted for a wide variety of purposes
– Control charts: Graphs used to study how a process changes over time
– Histogram: The most commonly used graph for showing frequency
distributions, or how often each different value in a set of data occurs
– Pareto chart: Shows on a bar graph which factors are more significant
– Scatter diagram: Graphs pairs of numerical data, one variable on each axis, to
look for a relationship
– Stratification: A technique that separates data gathered from a variety of
sources so that patterns can be seen (some lists replace "stratification" with
"flowchart" or "run chart")

36
Flowchart

37
Cause and Effect Diagram

38
Check Sheet

39
Control Chart

40
Histogram

41
Pareto Chart

42
Scatter Diagram

43
Stratification

44
 New Management and Planning
Tools
– Affinity diagram: organizes a large number of ideas into their natural relationships

– Relations diagram: shows cause-and-effect relationships and helps you analyze the natural
links between different aspects of a complex situation

– Tree diagram: breaks down broad categories into finer and finer levels of detail, helping you
move your thinking step by step from generalities to specifics

– Matrix diagram: shows the relationship between two, three or four groups of information and
can give information about the relationship, such as its strength, the roles played by various
individuals, or measurements

– Matrix data analysis: a complex mathematical technique for analyzing matrices, often replaced
in this list by the similar prioritization matrix. One of the most rigorous, careful and time-
consuming of decision-making tools, a prioritization matrix is an L-shaped matrix that uses
pairwise comparisons of a list of options to a set of criteria in order to choose the best option(s)

– Arrow diagram: shows the required order of tasks in a project or process, the best schedule for
the entire project, and potential scheduling and resource problems and their solutions

– Process decision program chart (PDPC): systematically identifies what might go wrong in a plan
under development

45
Affinity Diagram

46
Relations Diagram

47
Tree Diagram

48
 Matrix Diagrams
• L Shaped  
Customer Customer Customer Customer
D M R T

Purity % > 99.2 > 99.2 > 99.4 > 99.0

Trace metals (ppm) <5 — < 10 < 25

Water (ppm) < 10 <5 < 10 —

Viscosity (cp) 20-35 20-30 10-50 15-35

Color < 10 < 10 < 15 < 10

Drum   x    

Truck x      x

Railcar     x  

• T shaped

49
 Matrix Diagrams
• Y Shaped

• C shaped

50
 Matrix Diagrams
• X Shaped

• Roof shaped

51
Arrow Diagram

52
Process Decision Program Chart

53
MEASUREMENT
ETIQUETTE

The Human Angle

 The Human Angle

1. Why is the Human Angle important?

2. What problems may occur?
3. Do people like being measured?
4. Do we often measure the Producer, instead of
the Product?

Need for “ETIQUETTE” - Customary

Rules of Behavior
Functional Management
Set clear goals and get your staff to
help define metrics for success.
• Goal: Improve schedule accuracy
• Question: How accurate are your schedules?
Are your schedules improving?
• Metrics: Schedules slippage
• Results: Schedules improved over time
Functional Management
Don’t allow anyone in your organisation to use Metrics
to measure individuals
Understand the data that your people take pride in
reporting; don’t ever use it against them; don’t ever hint
that you might
Don't emphasize one metric to exclusion of others
– There is no single best Metric
– Look at the total picture
Project Management
Don’t measure individuals
Convince managers to use data in non-threatening
way
Convince people that process improvement is
important. Metrics will help.
Use team measures - not individual
Provide regular feedback to the team about the data
it helped to collect
Know the strategic focus of your organization and
emphasize metrics that support the strategy in your
organisation - What is important - Productivity, Back
log of service requests, customer satisfaction
Project Management
Gain agreement with your team on the metrics that you
will track and define them in a project plan
Emphasize the word - “team”
Metrics well understood
Ensures that Metrics are trackable and definable
Team agrees up front
Team agrees to go public with the data
Project Team
Do your best to report accurate, timely data
Even if you don’t understand, show respect
If you must joke, be sensitive to the data collector’s
sense of achievement
Support your people when their reports are backed
by useful data.
Example :
•Lab I :
– Online system for recording hours
– No training
– Abuse of system by automated inputs
•Lab II :
– Manual forms
– Charts displayed all over
– Impact of data discussed
Which Lab did better?
 Measurement Myths
- Howard Rubin

• Myth 1 : Measurement is Overhead

• Myth 2 : There is a best metric - Selecting it will solve
all measurement problems
• Myth 3 : The most critical success factor is choosing
the right metric
• Myth 4 : Metrics are forever. The Metrics chosen
today will be good for all time and circumstances
• Myth 5 : Leave the business of business
measurement to the business and let IT focus on its
internals (in peace).
 Conclusion
• Metrics are useful
• Metrics cannot be an ‘overnight phenomenon’
• Metrics are difficult, if not applied wisely, but
simple if applied with care
• METRICS ARE ESSENTIAL, AND A
COMPETITIVE ADVANTAGE.
 CONCLUSION
• DETERMINE Why you are measuring
• DETERMINE What you need to measure
• PLAN How you will measure

GO AHEAD, TAKE ACTION!