SCSA3002
QUALITY ENGINEERING
Prof. Dr. R. Aroul canessane,
CSE, Sathyabama Institute of Science
and Technology, Chennai.
COURSE OBJECTIVES
➢ To define quality assurance plans.
➢ To apply quality assurance tools and techniques.
➢ To understand the Clean Room Software
Engineering activities.
➢ To implement the tools for quality.
➢ To learn quality assurance models.
Course outcome
CO1 - Learn software quality factors.
CO2 - Apply common software testing strategies.
CO3 - Demonstrate about the project process control
and software Metrics.
CO4 - Implement all the common software testing
strategies.
CO5 - Understand the SQA standards and Software
process assessments.
CO6 - Deploy quality engineering models in projects
2
SYLLABUS - SCSA3002
UNIT 1 SOFTWARE QUALITY
Definition of Software Quality, Quality Planning, Quality system
– Quality Control Vs Quality Assurance – Product life cycle –
Project life cycle models. The Software Quality Challenge -
Software Quality Factors - Components of the Software Quality
Assurance System. Pre-Project Software Quality Components -
Contract Review - Development and Quality Plans.
UNIT 2 SOFTWARE ENGINEERING ACTIVITIES
Estimation, Software requirements gathering, Analysis,
Architecture, Design, development, Testing and Maintenance.
UNIT 3 SUPPORTING QUALITY ACTIVITIES Metrics,
Reviews –SCM – Software quality assurance and risk
management
UNIT 4 SOFTWARE QUALITY ENGINEERING TOOLS AND
TECHNIQUES
Seven basic Quality tools – Checklist – Pareto diagram – Cause
and effect diagram – Run chart –Histogram – Control chart –
Scatter diagram – Poka Yoke – Statistical process control –
Failure Mode and Effect Analysis – Quality Function deployment
– Continuous improvement tools – Case study.
UNIT 5 QUALITY ASSURANCE MODELS
Software Quality Standards, ISO 9000 series – CMM, CMMI – P-
CMM – Six Sigma – Malcolm Baldrige Quality - Case study.
Organization of this
Lecture:
Introduction Quality Engineering.
Quality control and Quality
Assurance
5
Software Quality
Conformance to explicitly stated functional
and performance requirements,
explicitly documented development
standards and
implicit characteristics that are expected of all
professionally develop software
Introduction
Traditional definition of
quality:
fitness of purpose,a quality
product does exactly what the
users want it to do.
9
Fitness of purpose
For software products,
fitness of purpose:
satisfaction of the
requirements specified in SRS
document.
10
Fitness of purpose
A satisfactory definition of
quality for many products: a car,
a table fan, a food mixer,
microwave oven, etc.
But, not satisfactory for
software products.
11
Introduction
Consider a software product:
functionally correct, i.e.
performs all functions as specified in
the SRS document,
but has an almost unusable
user interface. cannot be
considered as a quality product.
12
Introduction
Another example:
a product which does
everything that users want.
but has an almost
incomprehensible and
unmaintainable code.
13
Modern view of quality
Associates several quality factors with
a software product :
Correctness
Reliability
Efficiency (includes efficiency of resource utilization)
Portability
Usability
Reusability
Maintainability 12
Correctness
A software product is
correct,
if different requirements as
specified in the SRS document
have been correctly
implemented.
Accuracy of results. 15
Portability
A software product is said to be
portable,
if it can be easily made to work in
different operating systems,
in different machines,
with other software products, etc.
16
Reusability
A software product has good
reusability,
if different modules of the
product can easily be reused to
develop new products.
17
Usability
A software product has good
usability,
if different categories of users (i.e.
both expert and novice users) can
easily invoke the functions of the
product.
18
Maintainability
A software product is maintainable,
if errors can be easily corrected as and
when they show up,
new functions can be easily added to
the product,
functionalities of the product can be
easily modified, etc.
19
Software Quality
Management System
Quality management system
(or quality system):
principal methodology used by
organizations to ensure that the
products have desired
quality.
20
Software quality
Is achieved through a disciplined approach -
called software engineering SE
Can be defined, described, and measured
Can be assessed before any code has been
written
Cannot be tested into a product
21
Software quality challenges
Defining it
Describing it (qualitatively)
Measuring it (quantitatively)
Achieving it (technically)
22
Quality system
A quality system consists of the
following:
Managerial Structure
Individual Responsibilities.
Responsibility of the
organization as a whole.
23
Quality system
Every quality conscious organization has
an independent quality department:
performs several quality system activities.
needs support of top management.
Without support at a high level in a
company,
many employees may not take the quality
system seriously.
24
Quality System Activities:
Auditing of projects
Development of:
standards, procedures, and guidelines,
etc.
Production of reports for the
top management
summarizing the effectiveness of the
quality system in the organization.
Review of the quality system
itself. 25
Quality system
A good quality system must be well
documented.
Without a properly documented quality
system,
application of quality procedures become ad
hoc,
results in large variations in the quality of
the products delivered.
26
Quality system
An undocumented quality system:
sends clear messages to the staff about the
attitude of the organization towards quality
assurance.
International standards such as ISO
9000 provide:
guidance on how to organize a quality
system.
27
Evolution of Quality
Systems
Quality systems have evolved:
over the last five decades.
Prior to World War II,
way to produce quality products:
inspect the finished products
eliminate defective products.
28
Software Quality Factors
(by McCall)
Product Revision (changing it)
Flexibility (can I change it?)
Maintainability (can I fix it?)
Testability (can I test it?)
29
Software Quality Factors
(by McCall) contd.
Product Transition (modifying it to
work in a different environment)
Interoperability (Will I be able to
interface it with another system?)
Portability (Will I be able to use it on
another machine?)
Reusability (Will I be able to reuse
some of the software?)
30
Software Quality Factors
(by McCall) contd.
Product Operations (using it)
Correctness (Does it do what I want?)
Reliability (Does it do it accurately all of the
time?)
Efficiency (Will it run on my hardware
as well as it can?)
Integrity (Is it secure?)
31
Evolution of Quality
Systems
Since that time,
quality systems of
organizations have undergone
four stages of evolution.
32
Evolution of Quality
Systems
33
Evolution of Quality
Systems
Initial product inspection method :
gave way to quality control (QC).
Quality control:
not only detect the defective products
and eliminate them
but also determine the causes behind the
defects.
34
Quality control (QC)
Quality control aims at correcting
the causes of errors:
not just rejecting defective products.
Statistical quality control
quality of the output of the process is
inferred using statistical methods
in stead of inspection or testing of all
products
35
Quality control (QC)
The next breakthrough,
development of quality assurance
principles
36
Quality assurance
Basic premise of modern quality
assurance:
if an organization's processes are
good and are followed rigorously,
the products are bound to be of good
quality.
37
Quality assurance
All modern quality paradigms
include:
guidance for recognizing,
defining, analyzing, and improving
the production process.
38
Total quality management
(TQM)
Advocates:
continuous process
improvements through process
measurements.
39
SQA Activities
Quality assurance planning
Data gathering on key quality defining
parameters
Data analysis and reporting
Quality control mechanisms
40
Software Defects
The causes for not meeting the quality commonly
are
Imprecise requirement and software specifications
Lack of understanding of customer requirements
International deviations
Violation of standards (Design, Programming)
Erroneous data representation
Improper interface
Faulty logic in rules and processes
Erroneous testing
Incomplete and defective documentation
H&S platforms not coping up to required standards
Lack of domain knowledge
41
The nature of failure may be such
that one error may require only a
few repair, and other may need
hours.
A simple measure of reliability is Mean
Time between Failure (MTBF).
MTBF = MTTF + MTTR
Where MTTF is Mean Time to Failure and
MTTR is Mean Time to Repair.
42
SQA Components - SIX
43
SQA Components – contd.
1. Pre-project Components
❖Resources available
❖Budget
❖Contract review
2. Project Lifecycle Activities and Assessment
Development Lifecycle
❖formal design
❖expert opinion
❖software testing 42
-contd
3. Infrastructure components for error
prevention and Improvement
❖Procedures and Work Instructions
❖Supporting Quality Devices
❖Staff Training, Instruction and
Certification
❖Preventive and Corrective Actions
❖Documentation Control
45
- contd
4. Software Quality Management
5. SQA Standards, System Certification, and
Assessment Components
6. Organizing for SQA – The Human
Components
46
Business Process
reengineering
A term related to TQM.
Process reengineering goes a
step further than quality
assurance:
aims at continuous process
improvement.
47
Business Process
reengineering
• Our focus is reengineering of
the software process.
• Whereas BPR aims at
reengineering the way business
is carried out in any organization
• not just software development
organizations.
48
Total quality management
(TQM)
TQM goes beyond documenting
processes
optimizes them through redesign.
Over the years the quality paradigm
has shifted:
from product assurance to process
assurance.
49
How to Design and Implement
a Basic Quality Assurance Plan
. Design a means to effectively
document quality-related events (QREs)
and educate staff appropriately
root cause(s) for previous errors.
educate staff on documented QREs and their
resulting plans
errors reported to the Board due to poor
customer service
50
-contd
Identify one or two quality related
parameters you would like to measure
and improve.
Areas known to require improvement
Areas expected to be satisfactory (strengths)
51
-contd
Design a method to measure the
identified areas
Focus on quantitative measures that can show
clear results
Utilize your computer system’s capabilities
where appropriate
Consider a method that can be done
consistently as part of normal procedures
52
-contd
Set appropriate goals
Determine what is acceptable for your
practice
Set an attainable goal and be prepared to
update the goal when it is achieved.
53
-contd
Be prepared to make new plans when
goals are not met
Set a deadline for when unmet goals will be
addressed
Be prepared to change policies or procedures in
order to improve areas of deficiency
54
-contd
Educate your staff on the Quality
Assurance Plan, both at inception and
at regular intervals.
Why it is being done
What is being tracked
How to perform measurements
Progress in areas being monitored
55
-contd
Quality assurance never ends
Continue to update your plan as necessary.
Over time, the entire prescription process can be
monitored and improved.
56
Project Management
Some more terms…….
Project life cycle
Phases of a project
Phase exits or stage gates
Stakeholders
Project Life Cycle
Project management is about acquiring or
achieving the project goal
Most projects need to be broken down into a
logical sequence of ‘phases’, known as the project
life cycle.
Phases of a Project
Organisations normally break a project
down into several project phases for
better management control
Collectively, the project phases are known
How do you
as the project life cycle eat an
Each project phase is marked by the elephant?
completion of one or more
deliverables.
Stage Gates
Each phase ends with a review of the
deliverables and performance in order to
detect and correct errors and to decide if
the project should continue into the next
phase.
The phase end reviews are often called phase
exits or stage gates.
4 Phases of a Project
project initiation
project planning
project execution and control
project closure
Collectively these four phases represent the
‘project life cycle.’
4 Phases of a Project
Project Project Project Project
Initiation Planning execution closing
and control
Scope WBS Network Hand over
identification OBS diagrams Commission
Team set up Scheduling Reporting
Project
definition
Project life cycle
Project Life Cycle
Cost and staffing level
Initiation Planning Execution and control Closing
time
Project Life Cycle - Ideal v
Typical
Cost and staffing level
Initiation Planning Execution and control Closing
time
Exercise
What does the chart tell you about typical v
ideal project life cycle?
Answer
Many projects don’t get adequate resources in the
early stages
Low resourcing in the planning stage results in
delays in completing the project on time, to the
right quality and within the budget
Cost and staffing level
Initiation Planning Execution and control Closing
time
Allocation of time and
money…….
10% Initiation 20% Initiation
Planning Planning
25% 30%
60% Implementation 40% Implementation
5% 10% Closing
Closing
Typical Successful projects
Sydney Opera House
Good or bad project?
Sydney Opera House
Planned - 1959 to 1963 (4 years)
- $7 million
Actual - 1959 to 1973 (14 years)
- $100 million
Project Life Cycle (PLC) as a
Tool
PLC is a management tool to make it easier to
manage the project sequence
The choice of phases vary from industry to industry
and the PLC will vary to suit the needs of the
participants
Different project managers choose different PLC’s,
depending on the nature of the task i.e.
Engineering, software development etc.
Project Life Cycle (PLC) Uses
To maintain an overview of the project
To help identify tasks
Break the project into manageable parts
Integrate activities (bite sized chunks)
To help with the timing of decisions (go/no go)
To guide the level of contingency needed
Common characteristics of PLCs
Cost and staff levels low in early phases of the project
Probability of failure, risk and uncertainty are highest in the
early phases
Ability of stakeholders to influence the outcome of the
project are highest at the beginning of the project
Although many projects have similar phase names, with
similar work requirements, few are identical
Sub-projects within a project also have distinct project life
cycles
The Project Management
Dilemma
Managing stakeholders expectations can be
difficult because of the sometimes widely different
objectives of the various groups of stakeholders
Your understanding of the project needs to match stakeholders’ understanding.
Dr. Jana Jagodick
Work to make sure it is what you end up with!
Polytechnic of Namibia,
Common characteristics of PLCs
•Cost and staff levels low in early phases of the project
•Probability of failure, risk and uncertainty are highest in the
early phases
•Ability of stakeholders to influence the outcome of the
project are highest at the beginning of the project
•Although many projects have similar phase names, with
similar work requirements, few are identical
•Sub-projects within a project also have distinct project life
cycles
Dr. Jana Jagodick
Polytechnic of Namibia,
Goals of the project
Goal is the desired result of an activity,
which may be achieved within the limits
of a certain time interval.
Needs
Objective necessity
Wishes
Ideas
Aims (results)
What? How?
Aims (actions)
What? Who? With whom? When? With what?
How much is it?
Project execution
Fig. 1.5. Determination of project goals
Gold rule of project
management
Goals must have a clear
meaning. The results obtained in
achieving a goal must be measurable,
and the established constraints and
requirements, must be feasible, that is,
goals must be within the field of
acceptable solutions of the project
Determining a goal
Determining the goal is regarded as a
creative process, can be divided into a number
of certain procedures:
•determining the goal indicators,
•determining possible goals of the project,
•describing the goals of the project
Determining the goal indicators can be carried out
on the basis of:
•requirements of the project,
•the goals of the enterprise in which the project is
being executed,
•the study of the enterprise environment
Causes of New Product
Failures
•Overestimation of Market Size
•Product Design Problems
•Product Incorrectly Positioned, Priced or Advertised
•Costs of Product Development
•Competitive Actions
To create successful new products, the company
must:
understand it’s customers, markets and competitors
develop products that deliver superior value to customers.
New Product Development
Process
•Idea Generation and Screening
•Concept Development and Testing
•Marketing Strategy
•Business Analysis
•Product Development
•Test Marketing
•Commercialization
New Product Development Process
Step 1. Idea Generation
Systematic Search for New Product
Ideas
•Internal sources
•Customers
•Competitors
•Distributors
•Suppliers
New Product Development Process
Step 2. Idea Screening
Process to spot good ideas and drop poor
ones
Criteria
• Market Size
• Product Price
• Development Time & Costs
• Manufacturing Costs
• Rate of Return
New Product Development Process
Step 3. Concept Development & Testing
1. Develop Product Ideas into
Alternative
Product Concepts
2. Concept Testing - Test the
Product Concepts with Groups
of Target Customers
3. Choose the Best One
New Product Development Process
Step 4. Marketing Strategy Development
Marketing Strategy Statement Formulation
Part One - Overall:
Target Market
Planned Product Positioning
Sales & Profit Goals
Market Share
Part Two - Short-Term:
Product’s Planned Price
Distribution
Marketing Budget
Part Three - Long-Term:
Sales & Profit Goals
Marketing Mix Strategy
New Product Development Process
Step 5. Business Analysis
Step 6. Product Development
Business Analysis
Review of Product Sales, Costs,
and Profits Projections to See if
They Meet Company Objectives
If No, Eliminate
Product Concept
If Yes, Move to
Product Development
New Product Development Process
Step 7. Test Marketing
Standard
Controlled
Test Market
Test Market
Full marketing campaign A few stores that have
in a small number of agreed to carry new
representative cities. products for a fee.
Simulated
Test Market
Test in a simulated
shopping environment
to a sample of
consumers.
Product Life
Cycle
Sales and
Profits ($)
Sales
Profits
Time
Product Introduction Growth Maturity Decline
Develop-
ment
Losses/
Investments ($)
Introduction Stage of
the PLC
Sales Low sales
Costs High cost per customer
Profits Negative
Create product awareness
Marketing Objectives and trial
Product Offer a basic product
Price Use cost-plus
Distribution Build selective distribution
Advertising Build product awareness among early
adopters and dealers
Growth Stage of the PLC
Sales Rapidly rising sales
Costs Average cost per customer
Profits Rising profits
Marketing Objectives Maximize market share
Offer product extensions, service,
Product warranty
Price Price to penetrate market
Distribution Build intensive distribution
Advertising Build awareness and interest in the
mass market
Maturity Stage of the PLC
Sales Peak sales
Costs Low cost per customer
Profits High profits
Marketing Objectives Maximize profit while defending
market share
Product Diversify brand and models
Price Price to match or best competitors
Distribution Build more intensive distribution
Advertising Stress brand differences and benefits
Decline Stage of the PLC
Sales Declining sales
Costs Low cost per customer
Profits Declining profits
Marketing Objectives Reduce expenditure and milk the brand
Product Phase out weak items
Price Cut price
Go selective: phase out unprofitable
Distribution outlets
Advertising Reduce to level needed to retain
hard-core loyal customers
Pre-project SQA components
The SQA components belonging
here are meant to improve the
preparatory steps taken prior to
initiating work on the project itself
Pre-project SQA components
There are two components in
pre-project stage:
Contract reviews: Reviewing the
contract prior to final agreement
Development and quality plans:
Preparation of plans before the actual
work is performed
Pre project component:
Contract Review
Software may be developed within the framework of a
contract negotiated with a customer or in response to an
internal order originating in another department.
Contract review activities must include a detailed
examination of the project proposal draft and the
contract drafts.
Contract review is an important software quality
component because it ensures that we understand
and agree on all project details. It eliminates any
disagreement that might happen between the
project parties
Contract review activities include:
■ Clarification of the customer’s requirements
■ Review of the project’s schedule and resource
requirement estimates
■ Evaluation of the professional staff’s capacity to
carry out the proposed project
■ Evaluation of the customer’s capacity to fulfill his
obligations
■ Evaluation of development risks.
Contract review – a story
A happy gathering of the CFV project team at a popular
restaurant downtown was called to celebrate the
successful completion of a 10-month project for Carnegie
Fruits and Vegetables, a produce wholesaler. The new
information system registers product receipts from
growers, processes clients’ orders and produce shipments
to clients (greengrocers and supermarkets), bills clients,
and calculates payments made to the growers. The team
members were proud to emphasize that the project was
conducted in full as originally scheduled. The team was
especially jubilant as earlier that morning each member
had received a nice bonus for finishing on time.
Contract review – a story
The third speaker, the software company’s Vice President for
Finance, altered the pleasant atmosphere by mentioning that
this very successful project had actually lost about $90 000.
During his remarks, he praised the planners for their good
estimates of the resources needed for the analysis and design
phase, and for the plans for broad reuse of software from
other systems that were, this time, completely realized. “The
only phase where our estimates failed was one of the
project’s final phases, the client’s instruction, that
where
the client’s staff are instructed on how to use the new
information system. It now appears that no one had
read the relevant RFP (requirement for proposal)
section carefully
Contract review – a story
enough. This section stated in a rather innocuous
manner that the personnel in all the CFV branches
where the software was to be installed would be
instructed in its use by the software supplier.”
After a short pause he continued thus: “Nobody
tried to find out how many branches our client
operates. Nobody mentioned that CFV operates 19
branches – six of them overseas – before signing
the contract!”
Contract review – a story
He continued: “We tried to renegotiate the installation and
instruction budget items with the client, but the client insisted
on sticking to the original contract.” Though no names were
mentioned, it was clear that he blamed the sales negotiating
team for the loss.
Contract review is the software quality element that reduces
the probability of such undesirable situations. Contract review
is a requirement by the ISO 9001 standard and ISO 9000-3
Guidelines
Pre project component:
Development and quality
plans
Once a software development contract has been
signed or a commitment made to undertake an
internal project for the benefit of another
department of the organization, a plan is prepared of
the project (“development plan”) and its integrated
quality assurance activities (“quality plan”)
The main issues treated in the project development
plan are:
■ Schedules (What are tasks and how much time
is required)
■ Required manpower and hardware resources
■ Risk evaluations
■ Organizational issues: team members,
subcontractors and partnerships
■ Project methodology, development tools, etc.
■ Software reuse plans.
Software quality plan
A quality plan sets out (within a particular
project) the desired product qualities and how
these are assessed and define the most
significant quality attributes
It should define the quality assessment process
Software quality plan
Software quality plan is a document that describes
the quality activities of a software project that should
be implemented to ensure that the results of the
work performed will satisfy the users and achieve the
required quality.
Software quality plan
Usually a software quality plan includes:
■ Quality goals, expressed in the appropriate
measurable terms
■ Criteria for starting and ending each project stage
■ Lists of reviews, tests, and other scheduled
verification and validation activities.
Software quality plan
More details about how to prepare and implement a
software quality plan will be discussed latter.
