SlideShare a Scribd company logo
1
SWE3202: SOFTWARE TESTING,
INTEGRATION AND QUALITY ASSURANCE
LECTURE 004: SOFTWARE QUALITY ASSURANCE
VENUE: THEATER A
TIME: 10-12AM
2
OUTLINE OF PREVIOUS LECTURE
• DEBUGGING & SOFTWARE TESTING TOOLS
• Debugging.
• Classification of Defect.
• Process of Debugging.
• Example of programs to
debugs.
• Software Testing Tools.
3
TO BE DISCUSS
• SOFTWARE QUALITY AND ASSURANCE
• Quality.
• Software Quality.
• Software Quality factors/attributes.
• Software Quality Management.
4
SOFTWARE QUALITY
• For any delivered products or services the first questions that
may arise is: what is the Quality?
• Quality is consider very important because:
• - Quality is critical for survival and success (product,
organization).
• - End user/Customers demand quality.
• - Everybody wants quality.
• Quality is simply means that a product:
• Produced as per the predefine specifications.
• Fit for use on spot.
• Bug-free product.
5
SOFTWARE QUALITY CHALLENGES
• The measure for quality differ from project to project and
organization to organization.
• Quality measures used for small system may not be
appropriate for the large ones.
• Criteria for quality vary as a function of the specific
characteristics of the project, the need of the users and
stakeholders, and the application requirements of the
system and software.
• The criteria for quality applied to real-time application are
not relevant when dealing with system that are not real-time.
6
SOFTWARE QUALITY CHALLENGES
CONTD..
• The definition of quality is challenged by their viewpoints
and expectations on the products.
• E.g.
• Some end user/customers tailor quality from the product’s
security perspective and some from product’s performance
perspective.
7
SOFTWARE QUALITY CHALLENGES
• The issue is whose views, expectations, and aspirations
are to be considered supreme.
• The majority hold that end user/customer’s satisfaction
should be the goal for measuring software quality.
• But the customer may satisfied with a software quality,
of which the quality cannot be consider best, according
to software quality standard.
SOFTWARE QUALITY
What is software quality and how do we measure it?
customer’s viewpoint - meets specifications
developer’s viewpoint - easy to maintain, test, . . .
Other attributes of software that affect its quality:
– safety – understandability –
portability
– security – testability – usability
– reliability – adaptability –
reusability
– resilience – modularity – efficiency
– robustness – complexity –
learnability
è Software quality is not just about meeting
specifications and removing defects!
We need to select critical quality attributes early in the development
process and plan for how to achieve them.
SOFTWARE QUALITY ATTRIBUTES
1. Operational characteristics
correctness - the extent to which a program satisfies its
specification and fulfills the customers mission objectives
reliability - the extent to which a program can be expected to
perform its intended function with required precision.
efficiency - the amount of computing resources and code required
by a program to perform its function.
integrity - the extent to which access to software or data by
unauthorized persons can be controlled.
usability - the effort required to learn, operate, prepare input, and
interpret output of a program.
SOFTWARE QUALITY ATTRIBUTES
2. Changeability characteristics
maintainability - the effort required to locate and fix an error in a
program.
flexibility - the effort required to modify an operational program.
testability - the effort required to test a program to ensure that it
performs its intended function.
3. Adaptability characteristics
portability - the effort required to transfer the program from one
hardware and/or software system environment to another.
reusability - the extent to which a program (or its parts) can be
reused in other applications.
interoperability - the effort required to couple one system to
another.
How does the software quality attributes
interrelate
• It is not possible for any system to be optimized for all of these software qualities
attributes.
• So there is need to define the most important quality attributes for the software.
so that the developers working on the development can work together to achieve
it and sacrificed the others.
• Integrity vs efficiency
• The control access to data or software requires additional code and processing
leading to a longer runtime and additional storage requirement.
• Usability vs efficiency
• Improvement in human/computer interface may significantly the amount of
code and power required.
• Maintainability vs reusability
• Well structured and easily maintainable code is easier to reuse in other
program.
12
WHAT IS SOFTWARE QUALITY
• Conformance to explicitly stated functional and performance
requirements, standard development documentation and implicit
characteristics that are expected in professionally developed software.
• Software requirements are the foundation from which quality is
measured.
• Lack of conformance to requirements is lack of quality.
• Specified standards define a set of development criteria that guide the
manner in which software is engineered.
• If the criteria are not met, lack of quality will almost surely result.
• There is a set of implicit requirements that often goes unmentioned.
• If software conforms to its explicit requirements but fails to meet its
implicit requirements, software quality is suspect.
THE FOUR P’s IN SOFTWARE DEVELOPMENT
Product
Project
People
template
participate result
software engineers set of artifacts
set of activities
Process
Education & Training Management & monitoring Testing &
measurement
How can
we achieve
software quality?
Measurement & Feedback
Software Quality Management
1 - Quality Planning
2 - Quality Assurance
Software quality management is concerned with ensuring that developed
software systems are “fit for purpose.” That is, systems should meet the
needs of their users, should perform efficiently and reliably, and should
be delivered on time and within budget.
Software Quality Planning
• The first step of software quality management activity is planning,
where we need to identified the goals and what the baseline to be.
• The quality plan should set out the desired software qualities and
describe how these qualities are to be assessed.
• It defines what “high-quality” software actually means for a
particular system. Engineers, therefore, have a shared
understanding of the most important software quality attributes.
• We need to consider
- stakeholder’s expectation and priority
- What is company definition’s of success
- Legal standard or requirements that need to be abided by.
Software Quality Planning
Structure for software quality plan
• 1. Product introduction A description of the product, its intended
audience (market) and the quality expectations for the product.
• 2. Product plans: The critical release dates and responsibilities for the
product, along with plans for distribution and product servicing.
• 3. Process descriptions: The development and service processes and
standards that should be used for product development and
management.
• 4. Quality goals: The quality goals and plans for the product, including
an identification and justification of critical product quality attributes.
• 5. Risks and risk management: The key risks that might affect
product quality and the actions to be taken to address these risks.
SOFTWARE QUALITY ASSURANCE (SQA)
Quality assurance consists of those procedures, techniques, and
tools applied by professionals to ensure that a product meets or
exceeds pre-specified standards during it’s development cycle.
E.H. Bersoff
• Quality assurance
• It is an essential activity for any business that
produces products/services used by others.
• It needs to be planned and systematic
(It does not just happen).
• It needs to be built into the development process.
(A natural outcome of software engineering).
• Continuous improvement is the overall goal.
PRINCIPLES OF SOFTWARE QUALITY ASSURANCE
1. We have a set of standards and quality attributes that a software product
must meet.
There is a goal to achieve.
2. We can measure the quality of a software product.
There is a way to determine how well the product conforms to the
standards and the quality attributes.
3. We track the values of the quality attributes.
It is possible to assess how well we are doing.
4. We use information about software quality to improve the quality of future
software products.
There is feedback into the software development process.
SQA — AN UMBRELLA ACTIVITY
Quality
Standards
and
Procedures
Metrics
and
Measurement
Software
Configuration
Management
Testing
Formal
Technical
Reviews
Methods
and
Tools
SQA — AN UMBRELLA ACTIVITY
Includes all techniques used to improve the quality of the software:
1. methods and tools for System Requirements Capture,
System Analysis, System Design, Implementation and Testing
- to help ensure that we achieve a high quality system
2. Standards and procedures compliance
- to help ensure repeatability of the development process
3. metrics and measurement procedures
- to help us improve the software development process
4. formal technical reviews at each step
- to help uncover quality problems and to sign-off
5. software configuration management and change control
- to help ensure changes are managed and controlled.
6. multi-tiered testing
- to help ensure effective error detection.
1. encapsulate best (or most appropriate) practices
è acquired after much trial and error - helps avoid previous mistakes.
2. provide a framework around which to implement SQA process
è ensures that best practices are properly followed.
3. assist in ensuring continuity of project work
è reduces learning effort when starting new work
 product standards: define the characteristics all product artifacts should
exhibit so as to have quality.
 process standards: define how the software process should be conducted to
ensure quality software
SOFTWARE STANDARDS
Why are software standards important?
Each project needs to decide which standards should be:
ignored; used as is; modified; created.
Importance of software quality assurance
• 1. It ensures a high-quality software product: Software quality
assurance ensures that the software meets the specified quality
standards and requirements.
• This results in software that is more reliable, efficient, and user-friendly.
• 2. It saves time and money: SQA ensures that the developers find
bugs and errors at the early stages of software development.
• Thus, it requires less time and money to fix any one identified.
• 3. Protect company’s reputation: Businesses need to ensure that
their product works as intended before releasing it into the market.
• Therefore success/failure of a product after put into used, will significantly
impact company’s brand image and reputation as a whole.
Problems with quality of software assurance?
Despite the activities carries in to ensure the quality of the software, still find it difficult
to assure or guarantee the quality of the software product because of the below
reasons.
1. It is difficult to write complete and unambiguous software requirements.
- Software developers and customers may interpret the requirements in different ways,
and it may be impossible to reach agreement on whether or not software conforms to
its specification.
2. Specifications usually integrate requirements from several classes of
stakeholder.
- These requirements may not include the requirements of all stakeholder groups.
- The excluded stakeholders may look at the system as a poor-quality system, even
though it implements the agreed requirements.
3. It is impossible to measure certain quality attributes (e.g., maintainability)
directly.
PRODUCT QUALITY: DESIGN QUALITY METRICS
c) IEEE Standard 982.1-1988
• looks at: subsystem properties (number of subsystems and degree of
coupling)
database properties (number of attributes and classes)
è compute a design structure quality index—DSQI ® (0-1)
è used to compare with past designs; if DSQI is too low,
further design work and review may be required
 we can also consider changes made throughout the lifetime of the software and
compute how stable the product is (i.e., how many changes have been made in
subsystems in the current release)
è define a software maturity index—SMI ® (0-1)
è as SMI approaches 1, the product begins to stabilize
IEEE STANDARD 982.1-1988
S1 = the total number of subsystems defined in the program architecture
S2 = the number of subsystems whose correct function depends on the source of
data input or that produces data to be used elsewhere
S3 = the number of subsystems whose correct function depends on prior
processing
S4 = the number of database items (includes data objects and all attributes that
define objects)
S5 = the total number of unique database items
S6 = the number of database segments (different records or individual objects
S7 = the number of subsystems with a single entry and exit
IEEE STANDARD 982.1-1988
Program structure:
D1 = 1 if the architecture was developed using a distinct method
D1 = 0 otherwise
Subsystem independence: D2 = 1 - (S2/S1)
Subsystems not dependent on prior processing: D3 = 1 - (S3/S1)
Database size: D4 = 1 - (S5/S4)
Database compartmentalization: D5 = 1 - (S6/S4)
Subsystem entrance/exit characteristic: D6 = 1 - (S7/S1)
DSQI = wiDi wi = relative weighting of each Di
IEEE STANDARD 982.1-1988
SMI = [MT - (Fa + Fc + Fd)]
MT
MT = the number of subsystems in the current release
Fc = the number of subsystems in the current release that have
been changed
Fa = the number of subsystems in the current release that have
been added
Fd = the number of subsystems in the preceding release that were
deleted in the current release
PRODUCT QUALITY: PROGRAM QUALITY METRICS
a) Halstead’s Software Science
Looks at operators and operands in an implementation component and calculates
values for component volume, V, component difficulty, D, and effort, E, required to
implement the component.
n1 = number of unique operators in a component
n2 = number of unique operands in a component
N1 = the total number of operators
N2 = the total number of operands
L = N1+ N2 (component length)
V = L * log2(n1 + n2) (component volume in bits)
D = (n1/2) * (N2/n2) (difficulty of implementing the component)
E = V * D (effort required to implement the component)
For an implementation component, the key quality attributes are reliability and
difficulty of implementation.
PRODUCT QUALITY: PROGRAM QUALITY METRICS
b) McCabe’s Complexity Metric
Looks at control flow in a component.
Cyclomatic Complexity ® measures component’s logical complexity
è an indication of the testing difficulty of a component
Studies have shown a distinct relationship between the Cyclomatic Complexity of a
component and the number of errors found in the source code, as well as the time
required to find and fix errors.
c) Other program quality metrics
– length of code – length of identifiers
– depth of conditional nesting
Standards can be established to avoid complex components and/or highlight
problem components.
PRODUCT QUALITY: FORMAL APPROACHES
a) Proving programs/specifications correct
• logically prove that requirements have been correctly transformed into programs
(e.g., prove assertions about programs)
b) Statistical Quality Assurance
• categorize and determine cause of software defects
• 80-20 rule  80% of defects can be traced to 20% of causes
• isolate and correct 20% of the causes
è effort directed to things that cause the majority of defects
PROJECT QUALITY: REVIEWS
The principal method of validating the quality of a project.
Requirements
capture
Analysis
Design
Implementation
Testing
requirements
walkthroughs
analysis
walkthroughs
design
walkthroughs
code
walkthroughs
test plan
review
Leads to early
discovery of
defects
Requirements, Analysis and
Design
introduce 50-60%
of all defects.
Formal technical reviews
can uncover 75% of these!
Does process quality product quality?
PROCESS QUALITY
 unlike manufactured products, software development has some unique factors that affect
its quality:
– software is designed, not manufactured
– software development is creative, not mechanical
– individual skills and experience have a significant influence
– external factors (application novelty, commercial pressure)
è software development processes are organization specific
è people, technology may be more important than process
è insufficient resources will always adversely affect quality
PROCESS QUALITY: ISO 9001/ 9000-3
. . .
ISO 9000
quality model
Organization
quality model
Project 1
quality plan
Project 2
quality plan
Organizational
quality process
Project quality
management
instantiated as
instantiated as
documents
supports
is used
to develop
è certification is easy; can be a marketing ploy
generic
quality model
customized for
a particular
organization
Focus is on
process
management
Question?
Thank You

More Related Content

PPTX
Software Testing - Software Quality
PPT
Software Quality Assurance-se412-v11.ppt
PPTX
09 fse qualitymanagement
PPTX
Lec 1-SOFTWARE QUALITY ENGINEERING introduction (1).pptx
PDF
software testing and quality assurance .pdf
PPT
Software quality assurance lecture 1
PPTX
Software quality assurance
PPT
Quality Management.ppt in detail with notes
Software Testing - Software Quality
Software Quality Assurance-se412-v11.ppt
09 fse qualitymanagement
Lec 1-SOFTWARE QUALITY ENGINEERING introduction (1).pptx
software testing and quality assurance .pdf
Software quality assurance lecture 1
Software quality assurance
Quality Management.ppt in detail with notes

Similar to Fault code for the whole thing is that you have a (20)

PDF
Quality Assurance in Modern Software Development
PDF
Software Quality Assurance- Introduction
PPT
05_SQA_Overview.ppt
PPT
Software Quality Assurance presentation.
PPT
Reliability and Quality Issues Overview (5).ppt
PPT
1 sqa and testing concepts
PPT
Lecture10
PPTX
SQE Lecture 1.pptx
PPTX
Software engineering-5-1-SoftwareQuality.pptx
PPTX
Software Quality Assurance Introduction.pptx
PPT
3. quality.ppt
PPT
software-quality-assurance.pptQuality assurance consists of those procedures,...
PPTX
software quality planning and management
PPTX
Software quality assurance
PDF
Softwarequalityassurance with Abu ul hassan Sahadvi
PPTX
UNIT-1-INTRO.pptxsqa assurance testing sqa
PPTX
Software quality assurance
PPT
LECTURE 1 SQA.ppt
PPT
SQA_Lec#01-1.ppt
Quality Assurance in Modern Software Development
Software Quality Assurance- Introduction
05_SQA_Overview.ppt
Software Quality Assurance presentation.
Reliability and Quality Issues Overview (5).ppt
1 sqa and testing concepts
Lecture10
SQE Lecture 1.pptx
Software engineering-5-1-SoftwareQuality.pptx
Software Quality Assurance Introduction.pptx
3. quality.ppt
software-quality-assurance.pptQuality assurance consists of those procedures,...
software quality planning and management
Software quality assurance
Softwarequalityassurance with Abu ul hassan Sahadvi
UNIT-1-INTRO.pptxsqa assurance testing sqa
Software quality assurance
LECTURE 1 SQA.ppt
SQA_Lec#01-1.ppt
Ad

Recently uploaded (20)

PPTX
CHAPTER 2 - PM Management and IT Context
PDF
Navsoft: AI-Powered Business Solutions & Custom Software Development
PDF
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
PDF
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
PDF
System and Network Administration Chapter 2
PDF
How to Choose the Right IT Partner for Your Business in Malaysia
PPTX
Operating system designcfffgfgggggggvggggggggg
PDF
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
PDF
How Creative Agencies Leverage Project Management Software.pdf
PDF
Which alternative to Crystal Reports is best for small or large businesses.pdf
PPTX
ManageIQ - Sprint 268 Review - Slide Deck
PDF
AI in Product Development-omnex systems
PPTX
VVF-Customer-Presentation2025-Ver1.9.pptx
PPTX
Introduction to Artificial Intelligence
PDF
medical staffing services at VALiNTRY
PDF
Odoo Companies in India – Driving Business Transformation.pdf
PPTX
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
PDF
2025 Textile ERP Trends: SAP, Odoo & Oracle
PDF
Internet Downloader Manager (IDM) Crack 6.42 Build 41
PPTX
Online Work Permit System for Fast Permit Processing
CHAPTER 2 - PM Management and IT Context
Navsoft: AI-Powered Business Solutions & Custom Software Development
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
System and Network Administration Chapter 2
How to Choose the Right IT Partner for Your Business in Malaysia
Operating system designcfffgfgggggggvggggggggg
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
How Creative Agencies Leverage Project Management Software.pdf
Which alternative to Crystal Reports is best for small or large businesses.pdf
ManageIQ - Sprint 268 Review - Slide Deck
AI in Product Development-omnex systems
VVF-Customer-Presentation2025-Ver1.9.pptx
Introduction to Artificial Intelligence
medical staffing services at VALiNTRY
Odoo Companies in India – Driving Business Transformation.pdf
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
2025 Textile ERP Trends: SAP, Odoo & Oracle
Internet Downloader Manager (IDM) Crack 6.42 Build 41
Online Work Permit System for Fast Permit Processing
Ad

Fault code for the whole thing is that you have a

  • 1. 1 SWE3202: SOFTWARE TESTING, INTEGRATION AND QUALITY ASSURANCE LECTURE 004: SOFTWARE QUALITY ASSURANCE VENUE: THEATER A TIME: 10-12AM
  • 2. 2 OUTLINE OF PREVIOUS LECTURE • DEBUGGING & SOFTWARE TESTING TOOLS • Debugging. • Classification of Defect. • Process of Debugging. • Example of programs to debugs. • Software Testing Tools.
  • 3. 3 TO BE DISCUSS • SOFTWARE QUALITY AND ASSURANCE • Quality. • Software Quality. • Software Quality factors/attributes. • Software Quality Management.
  • 4. 4 SOFTWARE QUALITY • For any delivered products or services the first questions that may arise is: what is the Quality? • Quality is consider very important because: • - Quality is critical for survival and success (product, organization). • - End user/Customers demand quality. • - Everybody wants quality. • Quality is simply means that a product: • Produced as per the predefine specifications. • Fit for use on spot. • Bug-free product.
  • 5. 5 SOFTWARE QUALITY CHALLENGES • The measure for quality differ from project to project and organization to organization. • Quality measures used for small system may not be appropriate for the large ones. • Criteria for quality vary as a function of the specific characteristics of the project, the need of the users and stakeholders, and the application requirements of the system and software. • The criteria for quality applied to real-time application are not relevant when dealing with system that are not real-time.
  • 6. 6 SOFTWARE QUALITY CHALLENGES CONTD.. • The definition of quality is challenged by their viewpoints and expectations on the products. • E.g. • Some end user/customers tailor quality from the product’s security perspective and some from product’s performance perspective.
  • 7. 7 SOFTWARE QUALITY CHALLENGES • The issue is whose views, expectations, and aspirations are to be considered supreme. • The majority hold that end user/customer’s satisfaction should be the goal for measuring software quality. • But the customer may satisfied with a software quality, of which the quality cannot be consider best, according to software quality standard.
  • 8. SOFTWARE QUALITY What is software quality and how do we measure it? customer’s viewpoint - meets specifications developer’s viewpoint - easy to maintain, test, . . . Other attributes of software that affect its quality: – safety – understandability – portability – security – testability – usability – reliability – adaptability – reusability – resilience – modularity – efficiency – robustness – complexity – learnability è Software quality is not just about meeting specifications and removing defects! We need to select critical quality attributes early in the development process and plan for how to achieve them.
  • 9. SOFTWARE QUALITY ATTRIBUTES 1. Operational characteristics correctness - the extent to which a program satisfies its specification and fulfills the customers mission objectives reliability - the extent to which a program can be expected to perform its intended function with required precision. efficiency - the amount of computing resources and code required by a program to perform its function. integrity - the extent to which access to software or data by unauthorized persons can be controlled. usability - the effort required to learn, operate, prepare input, and interpret output of a program.
  • 10. SOFTWARE QUALITY ATTRIBUTES 2. Changeability characteristics maintainability - the effort required to locate and fix an error in a program. flexibility - the effort required to modify an operational program. testability - the effort required to test a program to ensure that it performs its intended function. 3. Adaptability characteristics portability - the effort required to transfer the program from one hardware and/or software system environment to another. reusability - the extent to which a program (or its parts) can be reused in other applications. interoperability - the effort required to couple one system to another.
  • 11. How does the software quality attributes interrelate • It is not possible for any system to be optimized for all of these software qualities attributes. • So there is need to define the most important quality attributes for the software. so that the developers working on the development can work together to achieve it and sacrificed the others. • Integrity vs efficiency • The control access to data or software requires additional code and processing leading to a longer runtime and additional storage requirement. • Usability vs efficiency • Improvement in human/computer interface may significantly the amount of code and power required. • Maintainability vs reusability • Well structured and easily maintainable code is easier to reuse in other program.
  • 12. 12 WHAT IS SOFTWARE QUALITY • Conformance to explicitly stated functional and performance requirements, standard development documentation and implicit characteristics that are expected in professionally developed software. • Software requirements are the foundation from which quality is measured. • Lack of conformance to requirements is lack of quality. • Specified standards define a set of development criteria that guide the manner in which software is engineered. • If the criteria are not met, lack of quality will almost surely result. • There is a set of implicit requirements that often goes unmentioned. • If software conforms to its explicit requirements but fails to meet its implicit requirements, software quality is suspect.
  • 13. THE FOUR P’s IN SOFTWARE DEVELOPMENT Product Project People template participate result software engineers set of artifacts set of activities Process Education & Training Management & monitoring Testing & measurement How can we achieve software quality? Measurement & Feedback
  • 14. Software Quality Management 1 - Quality Planning 2 - Quality Assurance Software quality management is concerned with ensuring that developed software systems are “fit for purpose.” That is, systems should meet the needs of their users, should perform efficiently and reliably, and should be delivered on time and within budget.
  • 15. Software Quality Planning • The first step of software quality management activity is planning, where we need to identified the goals and what the baseline to be. • The quality plan should set out the desired software qualities and describe how these qualities are to be assessed. • It defines what “high-quality” software actually means for a particular system. Engineers, therefore, have a shared understanding of the most important software quality attributes. • We need to consider - stakeholder’s expectation and priority - What is company definition’s of success - Legal standard or requirements that need to be abided by.
  • 16. Software Quality Planning Structure for software quality plan • 1. Product introduction A description of the product, its intended audience (market) and the quality expectations for the product. • 2. Product plans: The critical release dates and responsibilities for the product, along with plans for distribution and product servicing. • 3. Process descriptions: The development and service processes and standards that should be used for product development and management. • 4. Quality goals: The quality goals and plans for the product, including an identification and justification of critical product quality attributes. • 5. Risks and risk management: The key risks that might affect product quality and the actions to be taken to address these risks.
  • 17. SOFTWARE QUALITY ASSURANCE (SQA) Quality assurance consists of those procedures, techniques, and tools applied by professionals to ensure that a product meets or exceeds pre-specified standards during it’s development cycle. E.H. Bersoff • Quality assurance • It is an essential activity for any business that produces products/services used by others. • It needs to be planned and systematic (It does not just happen). • It needs to be built into the development process. (A natural outcome of software engineering). • Continuous improvement is the overall goal.
  • 18. PRINCIPLES OF SOFTWARE QUALITY ASSURANCE 1. We have a set of standards and quality attributes that a software product must meet. There is a goal to achieve. 2. We can measure the quality of a software product. There is a way to determine how well the product conforms to the standards and the quality attributes. 3. We track the values of the quality attributes. It is possible to assess how well we are doing. 4. We use information about software quality to improve the quality of future software products. There is feedback into the software development process.
  • 19. SQA — AN UMBRELLA ACTIVITY Quality Standards and Procedures Metrics and Measurement Software Configuration Management Testing Formal Technical Reviews Methods and Tools
  • 20. SQA — AN UMBRELLA ACTIVITY Includes all techniques used to improve the quality of the software: 1. methods and tools for System Requirements Capture, System Analysis, System Design, Implementation and Testing - to help ensure that we achieve a high quality system 2. Standards and procedures compliance - to help ensure repeatability of the development process 3. metrics and measurement procedures - to help us improve the software development process 4. formal technical reviews at each step - to help uncover quality problems and to sign-off 5. software configuration management and change control - to help ensure changes are managed and controlled. 6. multi-tiered testing - to help ensure effective error detection.
  • 21. 1. encapsulate best (or most appropriate) practices è acquired after much trial and error - helps avoid previous mistakes. 2. provide a framework around which to implement SQA process è ensures that best practices are properly followed. 3. assist in ensuring continuity of project work è reduces learning effort when starting new work  product standards: define the characteristics all product artifacts should exhibit so as to have quality.  process standards: define how the software process should be conducted to ensure quality software SOFTWARE STANDARDS Why are software standards important? Each project needs to decide which standards should be: ignored; used as is; modified; created.
  • 22. Importance of software quality assurance • 1. It ensures a high-quality software product: Software quality assurance ensures that the software meets the specified quality standards and requirements. • This results in software that is more reliable, efficient, and user-friendly. • 2. It saves time and money: SQA ensures that the developers find bugs and errors at the early stages of software development. • Thus, it requires less time and money to fix any one identified. • 3. Protect company’s reputation: Businesses need to ensure that their product works as intended before releasing it into the market. • Therefore success/failure of a product after put into used, will significantly impact company’s brand image and reputation as a whole.
  • 23. Problems with quality of software assurance? Despite the activities carries in to ensure the quality of the software, still find it difficult to assure or guarantee the quality of the software product because of the below reasons. 1. It is difficult to write complete and unambiguous software requirements. - Software developers and customers may interpret the requirements in different ways, and it may be impossible to reach agreement on whether or not software conforms to its specification. 2. Specifications usually integrate requirements from several classes of stakeholder. - These requirements may not include the requirements of all stakeholder groups. - The excluded stakeholders may look at the system as a poor-quality system, even though it implements the agreed requirements. 3. It is impossible to measure certain quality attributes (e.g., maintainability) directly.
  • 24. PRODUCT QUALITY: DESIGN QUALITY METRICS c) IEEE Standard 982.1-1988 • looks at: subsystem properties (number of subsystems and degree of coupling) database properties (number of attributes and classes) è compute a design structure quality index—DSQI ® (0-1) è used to compare with past designs; if DSQI is too low, further design work and review may be required  we can also consider changes made throughout the lifetime of the software and compute how stable the product is (i.e., how many changes have been made in subsystems in the current release) è define a software maturity index—SMI ® (0-1) è as SMI approaches 1, the product begins to stabilize
  • 25. IEEE STANDARD 982.1-1988 S1 = the total number of subsystems defined in the program architecture S2 = the number of subsystems whose correct function depends on the source of data input or that produces data to be used elsewhere S3 = the number of subsystems whose correct function depends on prior processing S4 = the number of database items (includes data objects and all attributes that define objects) S5 = the total number of unique database items S6 = the number of database segments (different records or individual objects S7 = the number of subsystems with a single entry and exit
  • 26. IEEE STANDARD 982.1-1988 Program structure: D1 = 1 if the architecture was developed using a distinct method D1 = 0 otherwise Subsystem independence: D2 = 1 - (S2/S1) Subsystems not dependent on prior processing: D3 = 1 - (S3/S1) Database size: D4 = 1 - (S5/S4) Database compartmentalization: D5 = 1 - (S6/S4) Subsystem entrance/exit characteristic: D6 = 1 - (S7/S1) DSQI = wiDi wi = relative weighting of each Di
  • 27. IEEE STANDARD 982.1-1988 SMI = [MT - (Fa + Fc + Fd)] MT MT = the number of subsystems in the current release Fc = the number of subsystems in the current release that have been changed Fa = the number of subsystems in the current release that have been added Fd = the number of subsystems in the preceding release that were deleted in the current release
  • 28. PRODUCT QUALITY: PROGRAM QUALITY METRICS a) Halstead’s Software Science Looks at operators and operands in an implementation component and calculates values for component volume, V, component difficulty, D, and effort, E, required to implement the component. n1 = number of unique operators in a component n2 = number of unique operands in a component N1 = the total number of operators N2 = the total number of operands L = N1+ N2 (component length) V = L * log2(n1 + n2) (component volume in bits) D = (n1/2) * (N2/n2) (difficulty of implementing the component) E = V * D (effort required to implement the component) For an implementation component, the key quality attributes are reliability and difficulty of implementation.
  • 29. PRODUCT QUALITY: PROGRAM QUALITY METRICS b) McCabe’s Complexity Metric Looks at control flow in a component. Cyclomatic Complexity ® measures component’s logical complexity è an indication of the testing difficulty of a component Studies have shown a distinct relationship between the Cyclomatic Complexity of a component and the number of errors found in the source code, as well as the time required to find and fix errors. c) Other program quality metrics – length of code – length of identifiers – depth of conditional nesting Standards can be established to avoid complex components and/or highlight problem components.
  • 30. PRODUCT QUALITY: FORMAL APPROACHES a) Proving programs/specifications correct • logically prove that requirements have been correctly transformed into programs (e.g., prove assertions about programs) b) Statistical Quality Assurance • categorize and determine cause of software defects • 80-20 rule  80% of defects can be traced to 20% of causes • isolate and correct 20% of the causes è effort directed to things that cause the majority of defects
  • 31. PROJECT QUALITY: REVIEWS The principal method of validating the quality of a project. Requirements capture Analysis Design Implementation Testing requirements walkthroughs analysis walkthroughs design walkthroughs code walkthroughs test plan review Leads to early discovery of defects Requirements, Analysis and Design introduce 50-60% of all defects. Formal technical reviews can uncover 75% of these!
  • 32. Does process quality product quality? PROCESS QUALITY  unlike manufactured products, software development has some unique factors that affect its quality: – software is designed, not manufactured – software development is creative, not mechanical – individual skills and experience have a significant influence – external factors (application novelty, commercial pressure) è software development processes are organization specific è people, technology may be more important than process è insufficient resources will always adversely affect quality
  • 33. PROCESS QUALITY: ISO 9001/ 9000-3 . . . ISO 9000 quality model Organization quality model Project 1 quality plan Project 2 quality plan Organizational quality process Project quality management instantiated as instantiated as documents supports is used to develop è certification is easy; can be a marketing ploy generic quality model customized for a particular organization Focus is on process management

Editor's Notes

  • #15: Here we determine what are the required quality standard, and the requirements necessary to meet these standard, and what procedure will be used to checks these criteria will be meet.
  • #18: How to ensure quality
  • #20: SQA—An Umbrella Activity 1. methods and tools for System Requirements Capture, System Analysis, System Design, Implementation and Testing to help ensure we achieve a high quality system 2. formal technical review procedures at each step to help uncover quality problems sign-off at each step 3. multi-tiered testing to help ensure effective error detection not a panacea! cannot uncover all errors 4. software configuration management and change control to help ensure changes are managed and controlled 5. standards compliance may not exist! if they exist, should be followed (or changed) may be mandated by law/contract (e.g., military) 6. metrics and measurement procedures establish and monitor software metrics historical record, institutional memory
  • #24: Measuring Software Quality—Metrics 1. IEEE Standard 982.1-1988 looks at subsystem properties (coupling) and data properties (size) design structure quality index (DSQI) ranges from 0 to 1 (1 is the best) compare to previous values; if too low  review design looks at number of changes made in each release (subsystems changed, added, deleted) software maturity index (SMI) as SMI approaches 1, product begins to stabilize
  • #30: Formal Approaches to SQA 1. Proving programs/specifications correct logically prove that requirements have been correctly transformed into programs 2. Statistical Quality Assurance categorize software defects and determine their cause isolate 20% of causes (vital few)  80-20 rule 80% of defects can be traced to 20% of all possible causes correct problems which cause 80% of defects (i.e., 20% of causes) can also use this technique to determine which phase in development process contributes most errors 3. The Cleanroom Process combination of 1. and 2.