This document discusses quality management in software projects. It describes quality management as having four main components: quality planning, quality control, quality assurance, and quality improvement. It also discusses various quality management techniques like software reviews, formal inspections, defect amplification and removal models, and statistical software quality assurance approaches like six sigma. The document emphasizes that quality management is important for project success and reducing costs from software defects.

1. QUALITY MANAGEMENT
Project Management Presentation
Presented By Muniba Noureen & Arooj Azeem
13 January 2016
1

2. Table of content
Quality Management
Software review
Formal inspections and technical review
Cost Impacts and software defects
Defect amplification and removal
Formal approaches to SQA
2

3. Presentation Mode: Group
Group introduction:
Presented to:
3
Muniba Noureen
• Roll no # 19
Arooj Azeem
• Roll no # 20
Ma ám Fakeeha Fatima

4. The Problem
 Low quality products are loss
 Customer dissatisfaction
 Services does not meet consistently
 Failure to meet the quality requirements
is common reason of project failure
83%
Top
Performance
44%
Everyone
else
4
Usage of software rate In 2011 survey

5. The solution
Quality Management
What is Quality Management?
A management process to develop and
manage the quality of a software to make
sure that the product satisfies the user.
It has four main components:
 Quality Planning
 Quality Control
 Quality Assurance
 Quality Improvement
5

6. “It costs a lot to produce a bad product”
Norman Augustin
6

7. Scope of Quality Management:
 Particularly Important for large and complex systems
 Quality documentation is record of progress
 Smaller systems require less documentation
 Focus on making quality culture
7

8. Components of Quality Management
Quality
Planning
Requirements must
be identified, a
criteria needs to be
set, and important
procedure must be
recognized as a part
of the plan.
Quality
Control
To review the quality
of the product or
service. Inspection
and testing is
necessary to identify
problems and defects
that need correction.
Through quality
improvement, the
results can be
measured and possible
improvements in
products can be made.
Quality
Assurance
Quality
Improvement
8
Companies need to
assure defects and
mistakes are avoided
in the manufacturing of
good and quality
assurance guarantees
consistent results.

9. Why Quality Management?
+80% projects are
successful
through Quality
Management with
decresed cost
9

10. The Quality
Results of Work Efforts
Total Cost
10

11. Software Review
 A process or meeting during which a software product
is examined by a project personnel, managers, users,
customers, user representatives, or other interested
parties for comment or approval

12. Varieties of Software Reviews
12
Software peer reviews are
conducted by the author of
the work product, or by one
or more colleagues of the
author, to evaluate the
technical content and/or
quality of the work
Software management
reviews are conducted by
management
representatives to evaluate
the status of work done and
to make decisions regarding
activities.

13. ISO 10018:2012 focuses on importance of people in quality
management
Quality Manager
People understanding
the importance of their
contribution and role in
the organization
Quality practitioners
People identifying their
constraints to
performance
Quality Management
Representative
People accepting their
ownership for problems
and their responsibilities
for solving them
Human Resource
Manager
People freely sharing
their knowlegde and
experience
13

14. Formal Inspections
 “Software Formal Inspections are a disciplined
engineering practice for detecting and correcting defects in
software and preventing their leakage into field operations.”
Don O'Neill

15. Steps of Formal Inspection Process
Planning: The inspection is planned by the moderator that how to conduct it.
Overview meeting: The author describes the background of the work product.
Preparation: Each inspector examines the work product to identify possible
defects.
Inspection meeting: During this meeting the reader reads through the work
product, part by part and the inspectors point out the defects for every part.
Rework: The author makes changes to the work product according to the action
plans from the inspection meeting.
Follow-up: The changes by the author are checked to make sure everything is
correct 15

16. Formal Technical Review
(1) It uncovers errors in function, logic, or
implementation
(2) to verify that the software under review meets
its requirements
(3) to ensure that the software according to
predefined standards;
(4) to achieve software that is developed in a
uniform manner;
(5) to make projects more manageable.

17. Formal Technical Review (cont..)
DefinitionBenefits
Formal technical review provides:
Defect information to the author.
Information on work product and development to peers.
Fault likelihood data to testers.
Product status to management
17

18. Cost Impact of Software Defects
 Defects are much more expensive to fix the later
they are discovered.
 A defect that isn't discovered until testing can be
100 times more expensive to repair than if it had
been discovered during a review.

19. For Example
 Assume that an error uncovered during design will
cost 1.0 monetary unit to correct.
 Relative to this cost, the same error uncovered just
before testing will cost 6.5 units; during testing, 15
units; and after release, between 60 and 100 units.

21. Defect Amplification and Removal
 A defect amplification model can be used to illustrate
the generation and detection of errors during the
preliminary design, detail design, and coding steps of
the software engineering process.
 During the step, errors may be mistakenly generated.
Review may fail to uncover newly generated errors
and errors from previous steps, resulting in some
number of errors that are passed through.

22. Reviews improve schedule performance
Req Design Code Test
R R R

23. Effectiveness of review  Defect Amplification and Removal
23

24. SQA Software Quality Assurance
 Umbrella activity applied throughout the software
process
 Planned and systematic pattern of actions required
to ensure high quality in software
 Responsibility of many stakeholders (software
engineers, project managers, customers,
salespeople, SQA group)

25. Statistical Software Quality Assurance
 Information about software defects is collected and
categorized
 An attempt is made to trace each defect to its
underlying cause
 Isolate the vital few causes of the major source of
all errors
 Then move to correct the problems that have
caused the defects

26. Statistical SQA – Categories of Errors
 Incomplete or erroneous specification (IES)
 Violation of programming standards (VPS)
 Error in data representation (EDR)
 Inaccurate or incomplete documentation (IID)
 Error in programming lang. Translation (PLT)
 Ambiguous or inconsistent human-computer
interface (HCI)

27. Statistical SQA – Six Sigma
Most widely used strategy for statistical SQA
Three core steps
 Define customer requirements, deliverables and
project goals via customer communication
 Measure the existing process and its output to
determine quality
If an existing software process is in place, but
improvement is required, six sigma suggests
 Improve the process by eliminating the root causes
of defects

28. Statistical SQA – Six Sigma (cont...)
 Control the process to ensure that future work does
not reintroduce the cases of defects
 Design the process to
□ avoid the root causes of defects
□ to meet customer requirements
 Verify that the process model will, in fact, avoid
defects and meet customer requirements

29. Thanks!
Any questions?

30. 30

31. References:
1) Wiegers, Karl E. (2001). Peer Reviews in Software: A
Practical Guide. Addison-Wesley.
p. 14. ISBN 0201734850.
2) Jump up^ Fagan, Michael E: "Design and Code
Inspections to Reduce Errors in Program
Development"
3) A Guide to the Project Management Body of
Knowledge, Fourth Edition, PMI, USA, 2008
4) Jump up^ Microsoft Solution Framework - Chapter 18
Stabilization phase, Published: April 27, 2005