1. Software Quality Assurance
Definition
Quality costs
Plan
Team
Characteristics
Implementation
documentation
Reviews & Audit

2. Definition Definition:
Software quality assurance is a planned and systematic pattern of actions that are required to ensure high quality in software.
Software Quality Assurance is an umbrella activity that is applied at each step in the process of building the software.
It is a planned and systematic set of activities necessary to provide adequate confidence that requirements are properly established and products or services conform to specified standards.

3. Three key stages in SQA Intermediate quality audit
ProducDesign review and document inspection
t and system inspection

4. Steps - SQA

5. Standards used Planning Analysis Review Configuration management
s/w testing
specifications

6. Quality Costs Prevention costs Appraisal costs Failure costs
quality planning, formal technical reviews, test equipment, training
Appraisal costs
in-process and inter-process inspection, equipment calibration and maintenance, testing
Failure costs
rework, repair, failure mode analysis
External failure costs
complaint resolution, product return and replacement, help line support, warranty work

7. Quality Assurance Plan
The plan for quality assurance activities should be in writing
Decide if a separate group should perform the quality assurance activities
Some elements that should be considered by the plan are: defect tracking, unit testing, source-code tracking, technical reviews, integration testing and system testing.

8. Quality Assurance Plan
Defect tracing – keeps track of each defect found, its source, when it was detected, when it was resolved, how it was resolved, etc.,
Unit testing – each individual module is tested
Source code tracing – step through source code line by line
Technical reviews – completed work is reviewed by peers
Integration testing -- exercise new code in combination with code that already has been integrated
System testing – execution of the software for the purpose of finding defects.

9. SQA Plan – 1 Management section Documentation section
describes the place of SQA in the structure of the organization
Documentation section
describes each work product produced as part of the software process
Standards, practices, and conventions section
lists all applicable standards/practices applied during the software process and any metrics to be collected as part of the software engineering work

10. SQA Plan - 2 Test section Reviews and audits section
references the test plan, procedure document and defines test record keeping requirements
Reviews and audits section
provides an overview of the approach used in the reviews and audits to be conducted during the project

11. SQA Plan - 3 Problem reporting and corrective action section Other
defines procedures for reporting, tracking, and resolving errors or defects, identifies organizational responsibilities for these activities
Other
tools, SQA methods, change control, record keeping, training, and risk management

12. SQA – Team Members i) Design and analysis team. ii) System team.
iii) Application support team.
iv) Testing team

13. Role Responsibilities Quality Coordinator
Responsible for ensuring all quality activities are planned and carried out accordingly
Responsible for ensure all team member are properly trained and equipped for their given roles and responsibilities
Ensures SQA activities align with available resources
Module Leader
coordinates activities related to a specific system module
Software Quality Leader
Responsible for leading SQA activities(i.e. coordinating reviews and walkthroughs)
Quality Reviewer
Reviews and identifies defects in project artifacts
Provides feedback for improved quality in software artifacts
SQA Team Member
Responsible for providing support during SQA activities by carrying out assigned tasks as they relate to quality of the system

14. Team(Traditional Organization View)

15. Functional Managers, Empowered Teams

16. Self-Organizing Product Teams

17. Characteristics Functionality Performance Constraints
Technical innovations
Technological and management risk

18. Implementation
The SQA team’s responsibility in this phase is to ensure the implementation of the proposed functions of the intended application.
Along with the implementation, the process of developing the application will also be monitored by the application.
There are a couple of design methods that could be used such as the language or framework and the SQA team should aid the development team in selecting the proper language and/or framework.

19. Documentation The SQA team’s responsibility in this phase.
To ensure the implementation of the proposed functions of the intended application.
Along with the implementation, the process of developing the application will also be monitored by the application.

22. Reviews and Audits

23. Reasons for Audit conducted
A specific project milestone has been reached and an audit is initiated as planned or as required by the auditing organization's charter.
External parties or customers request an audit of a specific item, at a specific date, or at a project milestone. This could be part of a contract agreement.
An internal organization has requested the audit, establishing a clear and specific need.

24. Software Reviews
Purpose is to find defects (errors) before they are passed on to another software engineering activity or released to the customer.
Software engineers (and others) conduct formal technical reviews (FTR) for software engineers.
Using formal technical reviews (walkthroughs or inspections) is an effective means for improving software quality.

25. Reviews
Reviews are the principle means of validating both process and product quality
Basic procedure is to have a group of people examine a process artifact to find potential problems
Common software review types include
defect inspection and removal (product)
progress reviews (product and process)
quality reviews (product and standards)

26. Quality Reviews
Group of knowledgeable people examines a software component and its documentation.
Code, design models, specifications, test plans, standards, etc. can be subjected to review.
Once an artifact (object or manufactured product) has been reviewed and ‘signed off’ by the reviewers, management has given its approval to proceed to the next stage of development

27. Quality Review Process
Select a review team
Arrange a time and place for the review
Distribute documents to review
Conduct the review
Complete the review forms
Decide whether to approve artifacts or have them reworked and review them again

28. Review Purposes Quality function Project management function
part of the general quality management process.
Project management function
provide information to project managers.
Training and communication function
product knowledge is shared among development team members.

29. Quality Review Results
Purpose is the discovery of system defects and inconsistencies
Review comments need to be classified as
no action (no changes to artifact are required)
refer for repair (author needs to correct faults)
reconsider overall design (problem identified impacts other design components)
Requirement and specification problems may require involvement of client to resolve

30. Review Roles Presenter (designer/producer).
Coordinator (not person who hires/fires).
Recorder
records events of meeting
builds paper trail
Reviewers
maintenance oracle (vision)
standards bearer
user representative
others

31. Formal Technical Reviews - 1
Involves 3 to 5 people (including reviewers)
Advance preparation (no more than 2 hours per person) required
Duration of review meeting should be less than 2 hours
Focus of review is on a discrete work product
Review leader organizes the review meeting at the producer's request.

32. Formal Technical Reviews - 2
Reviewers ask questions that enable the producer to discover his or her own error (the product is under review not the producer)
Producer of the work product walks the reviewers through the product
Recorder writes down any significant issues raised during the review
Reviewers decide to accept or reject the work product and whether to require additional reviews of product or not.

33. Why do peer reviews? To improve quality.
Catches 80% of all errors if done properly.
Catches both coding errors and design errors.
Enforce the spirit of any organization standards.
Training and insurance.

34. AUDIT

35. Software Quality Audit Roles and Processes
A software quality audit involves:
The client, person or organization which requests the audit,
The auditor or team who performs the audit, and
The auditiee whose work is being examined.

36. Client
The client (i.e., person or organization) is responsible for authorizing the audit and for defining the scope and identifying the requirements of the audit

37. Auditor or Audit Team determining the team size,
briefing team members on the audit scope and areas to be audited,
providing background about the organization being audited,
assigning the workload of who will audit what areas,
determining the audit schedule,
notifying and briefing the audited organization on the scope of the audit and materials that need to be provided,
ensuring that the audit team is prepared to conduct the audit,
ensuring that the audit plan or procedures are performed, and
issuing reports in accordance with the audit plan or procedures.

38. The auditee is responsible for:
participating in the audit,
providing all relevant materials and resources to the audit team,
understanding the concerns of the auditors and verifying their factual accuracy,
providing a response to the audit report, and
correcting or resolving deficiencies cited by the audit team.

39. SQA Group Activities - 1 Prepare SQA plan for the project.
Participate in the development of the project's software process description.
Review software engineering activities to verify compliance with the defined software process.

40. SQA Group Activities - 2
Audit designated software work products to verify compliance with those defined as part of the software process.
Ensure that any deviations in software or work products are documented and handled according to a documented procedure.
Record any evidence of noncompliance and reports them to management.

41. Formal SQA Approaches Proof of correctness.
Statistical quality assurance.
Cleanroom process combines items 1 & 2.

42. Reliability Metrics - part 1
Probability of Failure on Demand (POFOD)
POFOD = 0.001
For one in every 1000 requests the service fails per time unit
Rate of Fault Occurrence (ROCOF)
ROCOF = 0.02
Two failures for each 100 operational time units of operation

43. Reliability Metrics - part 2
Mean Time to Failure (MTTF)
average time between observed failures
( MTBF)
Availability = MTBF / (MTBF+MTTR)
MTTR -> Mean Time to Repair
MTBF -> Mean Time Between Failure
Reliability = MTBF / (1+MTBF)

44. Time Units Raw Execution Time Calendar Time Number of Transactions
non-stop system
Calendar Time
If the system has regular usage patterns
Number of Transactions
demand type transaction systems

45. Validation Perspectives
Reliability validation
Does measured system reliability meet its specification?
Is system reliability good enough to satisfy users?
Safety validation
Does system operate so that accidents do not occur?
Are accident consequences minimized?
Security validation
Is system secure against external attack?

46. Error Classifications
SQA should check that problems are classified.
A possible classification is:
User error;
User documentation error;
Coding error;
Design error;
Requirements specification error.
Problems may also be categorized by subsystem, or even software
SQA should use these statistics to evaluate product quality

47. The generic steps involved in an audit are:-
• Initiation
Scope
Frequency
• Preparation
Review of documentation
The programme
Working documents
• Execution
Opening meeting
Examination and evaluation
Collecting evidence
Observations
Close the meeting with the auditee

48. • Report.
- Preparation
- Content
- Distribution
• Completion.
-Report
-Submission
-Retention

49. The End.