SOFTWARE QUALITY

ENG

LECTURE 01 : WEEK 01

Credit : (3 + 0) / Week
 TEXT AND REF. BOOKS
2

Text Book:
Software Quality Engineering by
Jeff Tian IEEE

Reference Book:
Software Quality Engineering A
practitioners Approach IEEE
 SOFTWARE QUALITY
ASSURANCE ?
3 Presented by: Sumeera Hashmi
MS (Software Engineering)
BCIT(Ned University of Engineering and Technology)
Email : [email protected]
Quality ! What Is It ?
 Quality Not a single idea
many aspects
 Popular View

 In everyday life, usually thought of as intangible, can

be felt or judged, but not weighed or measured
 “I know it when I see it” - implies that it cannot
be controlled, managed, or quantified
 The standard of something measured against other
similar things, OR the degree of excellence of
something
Why Software quality?
 Quality a critical attribute of software product
 Financial
 Health
 Life loss
 Evolving Domain of SQ from technical
perspective to human aspects:
 Usability and Satisfaction
Why Software quality?
 Center of gravity shifts from creating
an engineering solution to satisfying the
stakeholders.
 Trend within the community of
stakeholders “I do not want to know
about bits and bytes, I want a
solution that satisfies my needs”
Why Software quality?
 Critical word “satisfaction”
 It covers both
 Functional perception of the software
solution
 Quality perception of the software solution
Why Software quality?
 Why software?
 In contemporary social life software, systems
and services rendered by software are
omnipresent, beginning with the watches to
nuclear electricity plant.
 Why quality?
 Because if these instances of software work
without the required quality we may be late,
dead or lost in space.
Why Software Quality
Assurance?
 A belief that
 Adherence to development process, as in
manufacturing, will lead to a quality product.
 Alternatively
 Process improvement will lead to a quality
product
Software Quality Challenge
 For user a software product is more and
more corresponds to a black box to
satisfy their business needs.
 Consequences
 Business needs drive quality software development.
 Stakeholder moves to the position of a car buyer and
user instead of being an involuntary expert in software
engineering.
Result
 User’s perspective of the end product is
the final judgement corresponds to
 Required functionality
 Required quality
 Absence of any one leads to a painful
process of negotiation, improvement and
often replacement of software product
or supplier.
Real World Software
Development
What is Software Quality?
 Software Quality is:
 The degree to which a system, component,
or process meets specified requirements
[Philip B. Crosby’s definition, 1979]
 The degree to which a system, component

or process meets customer or user needs

or expectations.
[Joseph M. Juran, 1988]
What exactly constitutes the
Quality?
 Hot debate why?
 No common agreement to what it
means, is it
 Customer Value
 Defect level
 or, fulfilled requirements?
Perspectives by Kitchenham & Pfleeger
1. Transcendental perspective
 Something towards which we are striving as an
ideal, but may never implement completely
2. User perspective
 Appropriateness of the product for a given
context of use
3. Manufacturing Perspective
 Degree of conformance to requirements
Perspectives by Kitchenham & Pfleeger
 Product perspective
 Inherent characteristics of the
product(measured in terms of defect rate ,#
bugs per line of code)
 Final perspective
 Different perspectives of quality may have a

different importance
Quality Assurance vs Quality
Control
 Definition
 QA is a set of activities for ensuring quality
in the processes by which products are
developed
 QC is a set of activities for ensuring quality
in products. The activities focus on
identifying defects in the actual products
produced
Quality Assurance vs Quality
Control
 Focus on
 QA aims to prevent defects with a focus on
the process used to make the product. It is
a proactive quality process.
 QC aims to identify (and correct) defects in
the finished product. Quality control,
therefore, is a reactive process
Quality Assurance vs Quality
Control
 What
 QA is prevention of quality problems
through planned and systematic activities
including documentation.

 QC is the set of activities or techniques

used to achieve and maintain the product
quality
Quality Assurance vs Quality
Control
 Tools and
 QA is managerial tool.
 QC is corrective tool
 Orientation
 QC is product oriented
 QA is process oriented
QA in Software Project developmen
QA in Software Project development
 software.
QA in Software Project development
 Defect Prevention in early stages
 Goal
 Error blocking to avoid data propagation and increasing cost over time to
or successive phases to fix defects
 Error Source
 Conceptual mistakes by designers and programmers
 Unfamiliarity with the product domain
 Techniques
 Inspection of requirement documents and product specification
 limitations
 Dynamic problems may only become apparent during execution
QA in Software Project
development
 limitations
 Dynamic problems may only become apparent during execution
 Inter-dependency only becomes apparent with the implementation of
related modules
 Defect Removal
 Because of the early phase testing limitations defect removal
techniques such as testing is performed in the middle to late
phases
 Failure Prevention and containment
 Fault tolerance and safety assurance are typically focus of
operational phase.
Defect Handling
 Defect Resolution
 Each discovered defect is corrected or taken
care of through appropriate channels
 Corrected or Fixed Defects
 Each defect needs to be verified to ensure failure
free executions, under the same execution
condition
 Not-Corrected Defects
 All parties must agree on the specific decision
Defect Handling
 Re-classification
 If a defect is later re-classified as not a defect, a
justification needs to be given and decision agreed
upon by the person who reclassify, the tester who
reported the defect and all other people.
 Deferred defects
 Considered to be minor and can be fixed in future
 Everyone involved must agree to this decision
Support Activities for Defect Resolution
 Defect logging
 Initial reporting and logging of defects. It

ensures that a record is kept for each

defect.
 Defect Tracking
 Monitors and record what happened to

each defect after its initial discovery, up

until its final resolution.
Exercise for next class
 A complete study of what tools are
being used for defect tracking and
monitoring.
 At least one tool should be completely
examined
Real World Software
Development
30 END OF LECTURE

Any Questions !!!