1. Software Quality Assurance
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

2. Quality (SWE 26.1) The American Heritage Dictionary defines quality as
“a characteristic or attribute of something.”
For software, two kinds of quality may be encountered:
Quality of design encompasses requirements, specifications, and the design of the system.
Quality of conformance is an issue focused primarily on implementation.
user satisfaction = compliant product + good quality + delivery within budget and schedule
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

3. Cost of Quality Prevention costs include
quality planning
formal technical reviews
test equipment
Training
Internal failure costs include
rework
repair
failure mode analysis
External failure costs are
complaint resolution
product return and replacement
help line support
warranty work
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

4. Software Quality (SWE 26.2)
Conformance to explicitly stated functional and performance requirements, explicitly documented development criteria standards, and implicit characteristics that are expected of all professionally developed software.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

5. SQA Activities Prepares an SQA plan for a project.
The plan identifies
evaluations to be performed
audits and reviews to be performed
standards that are applicable to the project
procedures for error reporting and tracking
documents to be produced by the SQA group
amount of feedback provided to the software project team
Participates in the development of the project’s software process description.
The SQA group reviews the process description for compliance with organizational policy, internal software standards, externally imposed standards (e.g., ISO-9001), and other parts of the software project plan.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

6. SQA Activities
Reviews software engineering activities to verify compliance with the defined software process.
identifies, documents, and tracks deviations from the process and verifies that corrections have been made.
Audits designated software work products to verify compliance with those defined as part of the software process.
reviews selected work products; identifies, documents, and tracks deviations; verifies that corrections have been made
periodically reports the results of its work to the project manager.
Ensures that deviations in software work and work products are documented and handled according to a documented procedure.
Records any noncompliance and reports to senior management.
Noncompliance items are tracked until they are resolved.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

7. McCall’s Triangle of Quality (SWE 15.1.1)b l y P o r t a b i l y F l e x i b t y R e u s a b i l t y T e s t a b i l y I n t e r o p a b i l y P R O D U C T E V I S N P R O D U C T A N S I P R O D U C T E A I N C o r e c t n s U s a b i l t y E f i c e n y R e l i a b t y I n t e g r i y
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

8. Product Operation Quality
Correctness: The program satisfies its specification and fulfills the customer objectives.
Reliability: The program is expected to perform its function with required precision.
Efficiency: The amount of resources required by the program to perform its function.
Integrity: Access to software or data by unauthorized users can be controlled.
Usability: The effort required to learn, operate, prepare input, and interpret output of a program.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

9. Product Revision Quality
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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

10. Product Transition Quality
Portability: The effort required to transfer a program from one hardware and/or software system environment to another.
Reusability: The extent to which a program or part of it can be reused in another application.
Interoperability: The effort required to couple one system to another.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

11. Defect Amplification and Removal
Illustrates the generation and detection of errors during preliminary design, detail design, and coding steps of a software.
Errors passed through
Errors from previous step
Errors to next step
% efficiency for error detection
Amplified errors
X ??
Newly Generated Errors
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

12. Example (No Review) 0% 6 10 0% 10 25 25 Preliminary Design 4X2 50%
Detail Design 0% 10
Code/unit test 10 6 6 0%
4X2 25
Integration test 4 39 10 10
20%
29X3 25 29
105
50%
Validation test 53
50%
System test 27
50% 14
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

13. Example (Review Conducted)
Preliminary Design
Detail Design
70% 10
Code/unit test 3 2 2
50%
1X2 25
Integration test 1 15 5 5
60%
10X3 25 10 24
50%
Validation test 12
50%
System test 6
50% 3
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

14. What Are Reviews?
a meeting conducted by technical people for technical people
a technical assessment of a work product created during the software engineering process
a software quality assurance mechanism
a training ground
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

15. The Players review leader producer reviewer recorder
standards bearer (SQA)
producer
maintenance
reviewer
recorder
user rep
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

16. Conducting the Formal Technical Review (FTR)1.
be prepared—evaluate product before the review 2.
review the product, not the producer 3.
keep your tone mild, ask questions instead
of making accusations 4.
stick to the review agenda 5.
raise issues, don't resolve them 6.
avoid discussions of style—stick to technical
correctness 7.
schedule reviews as project tasks 8.
record and report all review results
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

17. Review Options Matrix * IPR WT IN RRR trained leader
agenda established
reviewers prepare in advance
producer presents product
“reader” presents product
recorder takes notes
checklists used to find errors
errors categorized as found
issues list created
team must sign-off on result
IPR—informal peer review WT—Walkthrough
IN—Inspection RRR—round robin review no
maybe
yes no
yes no
yes no
maybe *
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

18. Sample-Driven Reviews (SDRs)
SDRs attempt to quantify those work products that are primary targets for full FTRs.
To accomplish this …
Inspect a fraction ai of each software work product, i. Record the number of faults, fi found within ai.
Develop a gross estimate of the number of faults within work product i by multiplying fi by 1/ai.
Sort the work products in descending order according to the gross estimate of the number of faults in each.
Focus available review resources on those work products that have the highest estimated number of faults.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

20. The SQA Plan
The Standard for SQA plans recommends a structure that identifies:
The purpose and scope of the plan.
A description of all software engineering work products.
All applicable standards and practices that are applied duing the software process.
SQA’s actions and tasks (including reviews and audits).
The tools and methods that support SQA actions and tasks.
Software configuration management procedures for management changes.
Methods for assembling, safeguarding, and maintaining all SQA related records.
Organizational roles and responsibilities relative to product quality.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005