The document outlines software quality assurance (SQA) as a systematic application of engineering principles in software development to ensure high quality and functional compliance with user requirements. Key aspects of software quality include good design, reliability, maintainability, and value for money, while SQA practices encompass various phases of software development, such as requirements definition, design, implementation, and testing. Various software process models, including the waterfall, prototyping, spiral, and iterative models, are described to illustrate how different methods organize software development tasks and manage quality assurance.

1. SOFTWARE QUALITY
ASSURANCE
PRESENTED BY
JESMIN ZAMAN

2. SOFTWARE ENGINEERING
Software engineering is the systematic application
of engineering approaches to the development of
software.
“software engineering” encompasses not just the
act of writing code, but all of the tools and
processes an organization uses to build and
maintain that code over time. It is a branch of
computer science that deals with the design,
implementation, and maintenance of complex
computer programs.

3. SOFTWARE QUALITY
The quality of software can be defined as the ability of the software to function as per
user requirement. When it comes to software products it must satisfy all the
functionalities written down in the SRS document.
Software quality reflects how well it complies with or conforms to a given design, based
on functional requirements or specifications. That attribute can also be described as the
fitness for purpose of a piece of software or how it compares to competitors in the
marketplace as a worthwhile product. It is the degree to which the correct software was
produced.

4. KEY ASPECTS THAT INCLUDE SOFTWARE QUALITY
• Good design – It’s always important to have a good and aesthetic design to please
users.
• Reliability – Be it any software it should be able to perform the functionality impeccably
without issues.
• Durability- Durability is a confusing term, In this context, durability means the ability of
the software to work without any issue for a long period of time.
• Consistency – Software should be able to perform consistently over platform and
devices.
• Maintainability – Bugs associated with any software should be able to capture and fix
quickly and news tasks and enhancement must be added without any trouble.
• Value for money – customer and companies who make this app should feel that the
money spent on this app has not gone to waste.

5. SOFTWARE QUALITY ASSURANCE (SQA)
Software quality assurance (SQA) is a means and
practice of monitoring the software engineering
processes and methods used in a project to ensure
proper quality of the software.
SQA encompasses the entire software development
process, including requirements engineering, software
design, coding, code reviews, source code control,
software configuration management, testing, release
management and software integration. It is organized
into goals, commitments, abilities, activities,
measurements, verification and validation.

6. QUALITY ASSURANCE ACTIVITIES
Quality assurance activities take place at each
phase of development. Analysts use application
technology and techniques to achieve high-quality
specifications and designs, such as model-driven
design. Engineers and technicians find bugs and
problems with related software quality through
testing activities. Standards and process
deviations are identified and addressed
throughout development by project managers or
quality managers, who also ensure that changes
to functionality, performance, features,
architecture and component (in general: changes
to product or service scope) are made only after
appropriate review, e.g. as part of change control
boards.

7. SOFTWARE PROCESS MODELS
A software development process is a method for developing computer software
that organizes the effort into a number of separate tasks and steps. This helps
make it possible to develop large software systems using many people in an
organized , manageable and trackable way, in order to retain control of the
development.

8. FUNDAMENTAL PROCESS ACTIVITIES OF
SOFTWARE PROCESS MODELS
All software process models share four fundamental process activities, and
differ primarily in how these four are organized and interleaved.
Specification:
• define requirements, functionality and constraints.
Development:
• build software to meet the specification.
Validation:
• validate that it does what the customer wants
Evolution:
• evolve to meet changing needs and expectations.

9. THE WATERFALL MODEL
Original Waterfall Model
First explicit model, derived from other engineering processes.

10. THE WATERFALL MODEL
(1) Requirements Analysis and Definition:
System’s required services, constraints and goals are established by
consultation with users/customers.
Expressed in a way understood and agreed to by both users and developers –
often test cases or scenarios.
Quality control – requirements reviews (inspection).
(2) System and Software Design
Partitions into hardware and software subsystems.
Establishes overall system and software architecture.
Establishes functional specifications for components of the architecture.
Quality control - design reviews (inspection).

11. THE WATERFALL MODEL
(3) Implementation and Unit Testing:
Design realized as a set of programs and program components (units) to
implement.
components of the architecture.
Verify that units meet functional specifications.
 Quality control - unit testing, component testing.
(4) Integration and System Testing:
Integrate individual programs and program units into complete system.
Validate system that system meets requirements.
Quality control - integration testing, acceptance testing.

12. THE WATERFALL MODEL
(5) Operation and Maintenance:
 Normally longest phase of software life cycle.
 Install system and put into use.
 Maintenance involves correcting errors discovered in practice (“failures”) and
improving system units (e.g., performance tuning) and enhancing services in
response to new requirements.
Quality control - regression testing, acceptance testing.
(6) Retirement and Decommissioning:
 System is retired and replaced with a new one.
Rarely done now because of cost and risk of replacement - continuous evolution
more Common.

13. THE PROTOTYPING MODEL
The steps are:
(1) Requirements Gathering and Analysis:
Much like waterfall model, but less stringent since prototype will help expose
inadequacies.
Quality control – requirements reviews (inspection).
(2) Quick Design:
Make a simple approximate initial design, refine during prototype iteration.
Quality control – prototype testing.
(3) Build Prototype:
Quickly hack together an approximate implementation showing salient external
features.
Quality control – essentially none.

14. THE PROTOTYPING MODEL
(4) Customer Evaluation:
Users validate prototype, report
inadequacies.
Quality control – acceptance testing and
evaluation (inspection).
(5) Design Refinement:
Refine design in response to user feedback
from prototype.
Quality control – design reviews (inspection).
(6) Full Scale Development
 Remaining stages of traditional waterfall
model.

15. THE SPIRAL MODEL
Boehm’s Spiral Model
 The Spiral Model is a refinement of the
waterfall model designed around
continuous documentation and evaluation
of risk.
Based on experience applying the
waterfall model to large (U.S.)
government software projects.
 Now a standard used by many
government agencies and software
providers.

16. THE SPIRAL MODEL
For each layer (phase) of the project:
(1)Determine Objectives
 Specific objectives (aims) for the phase of the project are defined
Constraints on the process and product are identified•
 Alternatives for achieving the objectives are identified
 Potential risks associated with each alternative are identified
(2) Assess and Reduce Risks
For each potential risk, a detailed analysis is carried out
Steps are taken to reduce risk (e.g., create prototype to check)
 Alternatives are chosen to minimize risk

17. THE SPIRAL MODEL
(3) Develop and Validate:
 Based on risk analysis, choose or modify development model.
 For example, to implement and validate,
 if user interface risks dominate, use evolutionary prototyping;
if safety risks are the major issue, use formal methods;
if integration problems are the big risk, use waterfall model.
(4) Review and Plan
Review and evaluate results of this phase (layer).
 Decide whether another layer of the spiral is needed.
 Draw up plans for next phase if so.

18. THE ITERATIVE DEVELOPMENT MODEL
Analysis of the problem domain and
definition of requirements begins
process as usual.
Need initial architecture design to
begin.
 Add most critical remaining
features each cycle.
Quality control: development of
test suite for new features on each
iteration.

19. Thank YOU