In this technique, test cases are developed using the use cases of the system. A use case encompass the various actors and their interactions with the system. Use cases cover the complete transactions from start to finish. These test cases depict the actual use of software by the end user.

1. Slides by Roger Pressman. 1
Chapter 5
Software Quality Assurance

2. Slides by Roger Pressman. 2
software quality assurance
The IEEE definition for software quality assurance
is as follows −
"A planned and systematic pattern of all actions
necessary to provide adequate confidence that an
item or product conforms to established technical
requirements. A set of activities designed to evaluate
the process by which the products are developed or
manufactured."

3. Slides by Roger Pressman. 3
What is Quality Assurance?
• Software Quality Assurance (SQA) is a set of activities for ensuring
quality in software engineering processes.
• It ensures that developed software meets and complies with the
defined or standardized quality specifications.
• SQA is an ongoing process within the Software Development Life
Cycle (SDLC) that routinely checks the developed software to
ensure it meets the desired quality measures.
• SQA practices are implemented in most types of software
development, regardless of the underlying software development
model being used

4. Slides by Roger Pressman. 4
Elements of SQA
• Standards
• Reviews and Audits
• Testing
• Error/defect collection and analysis
• Change management
• Education
• Vendor management
• Security management
• Safety
• Risk management

5. Slides by Roger Pressman. 5
McCall’s Factor Model
• This model classifies all software requirements into 11
software quality factors. The 11 factors are grouped into
three categories – product operation, product revision,
and product transition factors.
1. Product operation factors − Correctness, Reliability,
Efficiency, Integrity, Usability.
2. Product revision factors − Maintainability, Flexibility,
Testability.
3. Product transition factors − Portability, Reusability,
Interoperability.

6. Slides by Roger Pressman. 6
Software quality metrics
• Software quality metrics are a subset of software
metrics that focus on the quality aspects of the
product, process, and project.
Software quality metrics can be further divided into
three categories −
1. Product quality metrics
2. In-process quality metrics
3. Maintenance quality metrics

7. Slides by Roger Pressman. 7
Product Quality Metrics
1. Mean Time to Failure
2. Defect Density
3. Customer Problems
4. Customer Satisfaction
Mean Time to Failure
• It is the time between failures. This metric is mostly used with safety critical systems such as the
airline traffic control systems, avionics, and weapons.
Defect Density
• It measures the defects relative to the software size expressed as lines of code or function point,
etc. i.e., it measures code quality per unit. This metric is used in many commercial software
systems.
Customer Problems
• It measures the problems that customers encounter when using the product. It contains the
customer’s perspective towards the problem space of the software, which includes the non-defect
oriented problems together with the defect problems.

8. Slides by Roger Pressman. 8
In-process Quality Metrics
• In-process quality metrics deals with the tracking of defect arrival
This metric includes −
1. Defect density during machine testing
2. Defect arrival pattern during machine testing
3. Phase-based defect removal pattern
4. Defect removal effectiveness

9. Slides by Roger Pressman. 9
Maintenance Quality Metrics
• Although much cannot be done to alter the
quality of the product during this phase,
following are the fixes that can be carried out to
eliminate the defects as soon as possible with
excellent fix quality.
1.Fix backlog and backlog management index
2.Fix response time and fix responsiveness
3.Percent delinquent fixes
4.Fix quality

10. Slides by Roger Pressman. 10
SQA Activities
1. Process definition and implementation
2. Auditing
3. Training
Processes could be −
• Software Development Methodology
• Project Management
• Configuration Management
• Requirements Development/Management
• Estimation
• Software Design
• Testing, etc.
• Once the processes have been defined and implemented, Quality Assurance has the
following responsibilities −
1. Identify the weaknesses in the processes
2. Correct those weaknesses to continually improve the process

11. Components of SQA System
• An SQA system always combines a wide range of SQA components. These
components can be classified into the following six classes −
1. Pre-project components
• This assures that the project commitments have been clearly defined
considering the resources required, the schedule and budget; and the
development and quality plans have been correctly determined.
2.Components of project life cycle activities assessment
• The project life cycle is composed of two stages: the development life cycle
stage and the operation–maintenance stage.
• The development life cycle stage components detect design and
programming errors. Its components are divided into the following sub-
classes: Reviews, Expert opinions, and Software testing.
• The SQA components used during the operation–maintenance phase
include specialized maintenance components as well as development life
cycle components, which are applied mainly for functionality to improve the
maintenance tasks.
11
Slides by Roger Pressman.

12. Components of SQA System
3.Components of infrastructure error prevention and improvement
• The main objective of these components, which is applied throughout the entire organization, is to
eliminate or at least reduce the rate of errors, based on the organization’s accumulated SQA
experience.
4.Components of software quality management
• This class of components deal with several goals, such as the control of development and
maintenance activities, and the introduction of early managerial support actions that mainly
prevent or minimize schedule and budget failures and their outcomes.
5.Components of standardization, certification, and SQA system assessment
• These components implement international professional and managerial standards within the
organization. The main objectives of this class are utilization of international professional
knowledge, improvement of coordination of the organizational quality systems with other
organizations, and assessment of the achievements of quality systems according to a common
scale. The various standards may be classified into two main groups: quality management
standards and project process standards.
6.Organizing for SQA – the human components
• The SQA organizational base includes managers, testing personnel, the SQA unit and the
persons interested in software quality such as SQA trustees, SQA committee members, and SQA
forum members. Their main objectives are to initiate and support the implementation of SQA
components, detect deviations from SQA procedures and methodology, and suggest
improvements.
12
Slides by Roger Pressman.

13. Components of SQA System
Pre-project Software Quality Components
• These components help to improve the preliminary steps taken before starting a project. It includes −
1. Contract Review
2. Development and Quality Plans
Contract Review
• Normally, a software is developed for a contract negotiated with a customer or for an internal order to develop a
firmware to be embedded within a hardware product. In all these cases, the development unit is committed to an
agreed-upon functional specification, budget and schedule. Hence, contract review activities must include a
detailed examination of the project proposal draft and the contract drafts.
Specifically, contract review activities include −
1. Clarification of the customer’s requirements
2. Review of the project’s schedule and resource requirement estimates
3. Evaluation of the professional staff’s capacity to carry out the proposed project
4. Evaluation of the customer’s capacity to fulfil his obligations
5. Evaluation of development risks
13
Slides by Roger Pressman.

14. Components of SQA System
Pre-project Software Quality Components
Development and Quality Plans
• After signing the software development contract with an organization or an internal department of the same organization, a development
plan of the project and its integrated quality assurance activities are prepared. These plans include additional details and needed revisions
based on prior plans that provided the basis for the current proposal and contract.
• Most of the time, it takes several months between the tender submission and the signing of the contract. During these period, resources
such as staff availability, professional capabilities may get changed. The plans are then revised to reflect the changes that occurred in the
interim.
The main issues treated in the project development plan are −
1. Schedules
2. Required manpower and hardware resources
3. Risk evaluations
4. Organizational issues: team members, subcontractors and partnerships
5. Project methodology, development tools, etc.
6. Software reuse plans
The main issues treated in the project’s quality plan are −
Quality goals, expressed in the appropriate measurable terms
1. Criteria for starting and ending each project stage
2. Lists of reviews, tests, and other scheduled verification and validation activities
14
Slides by Roger Pressman.

15. Slides by Roger Pressman. 15
SQA Goals
• Requirements quality. The correctness, completeness, and
consistency of the requirements model will have a strong influence
on the quality of all work products that follow.
• Design quality. Every element of the design model should be
assessed by the software team to ensure that it exhibits high quality
and that the design itself conforms to requirements.
• Code quality. Source code and related work products (e.g., other
descriptive information) must conform to local coding standards and
exhibit characteristics that will facilitate maintainability.
• Quality control effectiveness. A software team should apply
limited resources in a way that has the highest likelihood of
achieving a high quality result.

16. Slides by Roger Pressman. 16
Statistical SQA
Product
& Process
measurement
... an understanding of how
to improve quality ...
Collect information on all defects
Find the causes of the defects
Move to provide fixes for the process

17. Slides by Roger Pressman. 17
Statistical SQA
• Information about software errors and defects is collected and
categorized.
• An attempt is made to trace each error and defect to its underlying
cause (e.g., non-conformance to specifications, design error,
violation of standards, poor communication with the customer).
• Using the Pareto principle (80 percent of the defects can be traced
to 20 percent of all possible causes), isolate the 20 percent (the vital
few).
• Once the vital few causes have been identified, move to correct the
problems that have caused the errors and defects.

18. Slides by Roger Pressman. 18
Six-Sigma for Software Engineering
• The term “six sigma” is derived from six standard
deviations—3.4 instances (defects) per million
occurrences—implying an extremely high quality
standard.
• The Six Sigma methodology defines these core steps:
1. Define customer requirements and deliverables and project
goals via well-defined methods of customer communication
2. Measure the existing process and its output to determine current
quality performance (collect defect metrics)
3. Analyze defect metrics and determine the vital few causes.
4. Improve the process by eliminating the root causes of defects.
5. Control the process to ensure that future work does not
reintroduce the causes of defects.

19. Slides by Roger Pressman. 19
ISO 9001:2000 Standard
• ISO 9001:2000 is the quality assurance standard that applies to
software engineering.
• The standard contains 20 requirements that must be present for an
effective quality assurance system.
• The requirements delineated by ISO 9001:2000 address topics such
as
– management responsibility, quality system, contract review, design
control, document and data control, product identification and
traceability, process control, inspection and testing, corrective and
preventive action, control of quality records, internal quality audits,
training, servicing, and statistical techniques.

20. What is Reliability Testing?
• Software reliability testing a testing technique that relates
to testing a software's ability to function given
environmental conditions consistently that helps uncover
issues in the software design and functionality.
Parameters involved in Reliability Testing:
1. Dependent elements of reliability Testing:
2. Probability of failure-free operation
3. Length of time of failure-free operation
4. The environment in which it is executed
Key Parameters that are measured as part of reliability are
given below:
1. MTTF: Mean Time To Failure
2. MTTR: Mean Time To Repair
3. MTBF: Mean Time Between Failures (= MTTF + MTTR)
20
Slides by Roger Pressman.

21. Software Maintenance
• Software maintenance is widely accepted part of SDLC now a days. It stands for all
the modifications and updations done after the delivery of software product. There
are number of reasons, why modifications are required, some of them are briefly
mentioned below:
1. Market Conditions - Policies, which changes over the time, such as taxation and
newly introduced constraints like, how to maintain bookkeeping, may trigger need for
modification.
2. Client Requirements - Over the time, customer may ask for new features or functions
in the software.
3. Host Modifications - If any of the hardware and/or platform (such as operating
system) of the target host changes, software changes are needed to keep
adaptability.
4. Organization Changes - If there is any business level change at client end, such as
reduction of organization strength, acquiring another company, organization venturing
into new business, need to modify in the original software may arise 21
Slides by Roger Pressman.

22. Types of maintenance
• In a software lifetime, type of maintenance may vary based on its
nature.
1. Corrective Maintenance - This includes modifications and
updations done in order to correct or fix problems, which are either
discovered by user or concluded by user error reports.
2. Adaptive Maintenance - This includes modifications and updations
applied to keep the software product up-to date and tuned to the
ever changing world of technology and business environment.
3. Perfective Maintenance - This includes modifications and updates
done in order to keep the software usable over long period of time.
It includes new features, new user requirements for refining the
software and improve its reliability and performance.
4. Preventive Maintenance - This includes modifications and
updations to prevent future problems of the software. It aims to
attend problems, which are not significant at this moment but may
cause serious issues in future.
22
Slides by Roger Pressman.

23. Maintanence Activities
23
Slides by Roger Pressman.

24. Software Configuration Management
• Software Configuration Management(SCM) is a
process to systematically manage, organize, and
control the changes in the documents, codes,
and other entities during the Software
Development Life Cycle.
• The primary goal is to increase productivity with
minimal mistakes. SCM is part of cross-
disciplinary field of configuration management
and it can accurately determine who made
which revision.
24
Slides by Roger Pressman.

25. Tasks in SCM process
• Configuration Identification
• Baselines
• Change Control
• Configuration Status Accounting
• Configuration Audits and Reviews
25
Slides by Roger Pressman.

26. Tasks in SCM process
• Configuration Identification:
• Configuration identification is a method of determining the scope of the software
system. With the help of this step, you can manage or control something even if you
don't know what it is. It is a description that contains the CSCI type (Computer
Software Configuration Item), a project identifier and version information.
• Baseline:
• A baseline is a formally accepted version of a software configuration item. It is
designated and fixed at a specific time while conducting the SCM process. It can only
be changed through formal change control procedures.
• Change Control:
• Change control is a procedural method which ensures quality and consistency when
changes are made in the configuration object. In this step, the change request is
submitted to software configuration manager.
• Configuration Status Accounting:
• Configuration status accounting tracks each release during the SCM process. This
stage involves tracking what each version has and the changes that lead to this
version
• Configuration Audits and Reviews:
• Software Configuration audits verify that all the software product satisfies the
baseline needs. It ensures that what is built is what is delivered.
26
Slides by Roger Pressman.

27. Software Re-engineering
• When we need to update the software to keep it to the current
market, without impacting its functionality, it is called software re-
engineering. It is a thorough process where the design of software is
changed and programs are re-written.
• Legacy software cannot keep tuning with the latest technology
available in the market. As the hardware become obsolete, updating
of software becomes a headache. Even if software grows old with
time, its functionality does not.
• For example, initially Unix was developed in assembly language.
When language C came into existence, Unix was re-engineered in
C, because working in assembly language was difficult.
• Other than this, sometimes programmers notice that few parts of
software need more maintenance than others and they also need re-
engineering.
27
Slides by Roger Pressman.

28. Re-Engineering Process
• Decide what to re-engineer. Is it whole software or a part of it?
• Perform Reverse Engineering, in order to obtain specifications of
existing software.
• Restructure Program if required. For example, changing function-
oriented programs into object-oriented programs.
• Re-structure data as required.
• Apply Forward engineering concepts in order to get re-engineered
software.
28
Slides by Roger Pressman.

29. Reverse Engineering
• It is a process to achieve system specification by thoroughly
analyzing, understanding the existing system. This process can be
seen as reverse SDLC model, i.e. we try to get higher abstraction
level by analyzing lower abstraction levels.
• An existing system is previously implemented design, about which
we know nothing. Designers then do reverse engineering by looking
at the code and try to get the design. With design in hand, they try to
conclude the specifications. Thus, going in reverse from code to
system specification.
29
Slides by Roger Pressman.

30. 30
Slides by Roger Pressman.
Forward Engineering
1. The cost to maintain one line of source code may be 20 to 40
times the cost of initial development of that line.
2. Redesign of the software architecture (program and/or data
structure), using modern design concepts, can greatly facilitate
future maintenance.
3. Because a prototype of the software already exists,
development productivity should be much higher than average.
4.The user now has experience with the software. Therefore, new
requirements and the direction of change can be ascertained with
greater ease.
5.CASE tools for reengineering will automate some parts of the
job.
6. A complete software configuration (documents, programs and
data) will exist upon completion of preventive maintenance.

31. 31
Slides by Roger Pressman.
Computer Aided Software Engineering TOOLS
• CASE stands for Computer Aided Software Engineering. It means,
development and maintenance of software projects with help of various
automated software tools.
• CASE Tools
• CASE tools are set of software application programs, which are used to
automate SDLC activities. CASE tools are used by software project
managers, analysts and engineers to develop software system.
• There are number of CASE tools available to simplify various stages of
Software Development Life Cycle such as Analysis tools, Design tools,
Project management tools, Database Management tools, Documentation
tools are to name a few.
• Use of CASE tools accelerates the development of project to produce
desired result and helps to uncover flaws before moving ahead with next
stage in software development.

32. Categories of CASE Tools
• CASE tools can be broadly divided
into the following parts based on their
use at a particular SDLC stage:
Case Tools
• Upper Case Tools - Upper CASE tools are
used in planning, analysis and design
stages of SDLC.
• Lower Case Tools - Lower CASE tools are
used in implementation, testing and
maintenance.
• Integrated Case Tools - Integrated CASE
tools are helpful in all the stages of SDLC,
from Requirement gathering to Testing and
documentation.
• CASE tools can be grouped together if they
have similar functionality, process activities
and capability of getting integrated with
other tools.
32
Slides by Roger Pressman.

33. Enf of Chapter 5
• Good Luck..Dear Students
33
Slides by Roger Pressman.