SPM

Course Code: SE211

Lecture # 23

By
Mr. Abid Jameel

Department of Computer Science,

International Islamic University, Islamabad.
1
 Project Planning

- Quality Concepts
- Quality
- Quality Control
- Quality Assurance
- Cost of Quality
- Software Quality Assurance
- Software Reviews
- Formal Technical Reviews
- The Review Meeting
- Review Reporting and Record Keeping
- Review Guidelines
- Formal Approaches to SQA
- Statistical Quality Assurance
- Software Reliability
- The SQA Plan
 Quality Concepts

• Software Quality assurance (SQA) is one of the main objectives of the software

engineering.

• SQA means “the end product is exactly according to the needs, specifications, and

expectations of its end users and it has all the desirable features in it”.

• Whenever & wherever we produce something, demand of quality is the basic one.

• Everyone seem to be demanding quality in the word of science & technology.

• But, perhaps only a few persons know the exact meaning of word “Quality”.
 Quality Concepts

• Quality means measureable characteristics (attributes) of some thing.

• As regard software products, quality can be of two types.

1. Quality of Design
2. Quality of Conformance

1. Quality of Design

• Quality of Design means the characteristics of end products (s/w), which is specified by

the designer.

• High level of s/w & h/w resources, effective error handling, and good performance are

the important characteristics which improve the quality of design of any s/w product.
 Quality Concepts
1. Quality of Conformance

• Quality of conformance is the level to which design specifications or characteristics are

followed during development of software.

• Quality of conformance relates to the implementation phase of a s/w project and assure

end product is exactly according to the design specifications?

 Quality Control

• Quality Control – is the process or the series of inspections, reviews, and test used

which are conducted throughout the develop cycle of a software product.

• After this process, the end product should meet the requirements that were expected

by its designers & users.

• Quality control includes a feedback loop to the process.

• Objective: is to minimize the produced defects, increase the product quality

Implementation approaches:

Key concept of quality control:

• compare the work products with the specified and measurable standards
 Quality assurance

• It assure the management of s/w project that the end product is of good quality.

• This assure is made through different auditing and retorting functions.

• If data provided by these functions shows that there are some quality problems, the

management should consider alternates to rectify (correction) the problems.

 Cost of Quality
• It is not easy task to produce a good quality product.
• A large amount is required to produce a good quality product.
• Cost of quality includes all costs required in performing quality related activities.
• Quality cost may be sub-divided into prevention, appraisal, & failure.

- prevention cost are consumed in:

- planning of quality
- technical feasibility studies
- testing of H/w & S/w
- training of users
- appraisal (evaluation) costs are consumed in:
- in-process and inter-process inspection of s/w modules
- equipment installation & maintenance
- testing of results
- failure cost:
internal failure cost:
- rework, repair, and failure mode analysis
external failure cost:
- complaint resolution
- product return and replacement
- help line support
- warranty work
 Software Quality Assurance

Goal: to achieve high-quality software product

Three import points for quality measurement:

- Use requirements as the foundation
- Use specified standards as the criteria
- Considering implicit requirements

About quality assurance:

- The first formal quality assurance and control function was

introduced at Bell Labs in 1916 in the manufacturing world.

- During the 1950s and 1960s, the programmers controls their product quality.

- During the 1970s, quality assurance standards were introduced first in

military contract software development.

- In 1987, the extending definition is given in [SCH87].

 SQA Group

Who involves quality assurance activities?

Software engineers, project managers, customers, sale people, SQA group

Engineers involved the quality assurance work:

- apply technical methods and measures
- conduct formal technical review
- perform well-planned software testing

The SQA group’s role -> serves as the customer’s in-house representative
assist the software engineering team in achieving high-quality

The SQA group’s responsibility:

- quality assurance planning oversight, record keeping, analysis and reporting

The SQA group’s tasks:

- Prepare a SQA plan for a project

- Participate in the development of the project’s software process description
- Review engineering activities to verify compliance with the defined process
- Audits designated software work products to verify compliance the defined process
- Ensure the deviations in software work and products according to a documented procedure
- Records any noncompliance and reports to senior management
 Software Reviews
What is software reviews?
- a “filter” for the software engineering process.

Purpose: serves to uncover errors in analysis, design, coding, and testing.

A review --> a way to

- identify the needed improvements of the parts in a product
- confirm the improvement parts of a product.
- achieve technical work of more uniform, predictable, and manageable.

Different types of reviews:

- Informal reviews:
informal meeting and informal desk checking
- Formal reviews: (design to an audience of customers, management, and staff)
Walkthrough, inspection, and round-robin reviews

The terms “defect” and “fault” are synonymous

--> quality problems found after software release

Software “error” refers to a quality problem found b y engineers before software release
 Formal Technical Reviews (FTR)

Objectives of FTR:

- to uncover errors in function, logic, or implementation

- to verify the software under review meets its requirements
- to ensure that the software has been represented according to predefined standards
- to develop software in a uniform manner
- to make projects more manageable

Purposes of FTR:

- serves as a training ground for junior engineers

- promote backup and continuity

Review meeting’s constraints:

- 3-5 people involved in a review
- advanced preparation (no more than 2 hours for each person)
- the duration of the review meeting should be less than 2 hours
- focus on a specific part of a software product

People involved in a review meeting:

- producer, review leader, 2 or 3 reviewers (one of them is recorder)
 Formal Technical Review Meeting
The preparation of a review meeting:
- a meeting agenda and schedule (by review leader)
- review material and distribution (by the producer)
- review in advance (by reviewers)

Review meeting results:

- a review issues list
- a simple review summary report (called meeting minutes)
- meeting decisions:
- accept the work product w/o further modification
- reject the work product due to errors
- accept the work under conditions (such as change and review)
- sign-off sheet

Review summary report (a project historical record) answers the following questions:
- what was reviewed?
- who reviewed it?
- what were the findings and conclusions

Review issues list serves two purposes:

- to identify problem areas in the project
- to serve as an action item checklist (a follow-up procedure is needed)
 Review Guidelines (for FTR)

A minimum set of guidelines for FTR:

- Review the product, not the producer

- Set an agenda and maintain it
- Limit debate and rebuttal (blames)
- Articulate problem areas, but don’t attempt to solve every problem noted
- Take written notes
- Limit the number of participants and insist upon advance preparation
- Develop a checklist for each work product that is likely to be reviewed
- Allocate resources and time schedule for FTRs
- Conduct meaningful training for all reviewers
- Review your early reviews
 Statistical Quality Assurance
Statistical quality assurance reflects a growing trend throughout industry to become more
quantitative about quality.

Statistical quality assurance implies the following steps:

- Information about software defects is collected and categorized
- An attempt is made to trace each defect to its underlying cause
Causes of errors:
- incomplete or erroneous specification (IES)
- misinterpretation of customer communication (MCC)
- intentional deviation from specification (IDS)
- violation of programming standards (VPS)
- error in data representation (EDR)
- inconsistent module interface (IMI)
- error in design logic (EDL)
- incomplete or erroneous testing (IET)
- inaccurate or incomplete documentation (IID)
- error in programming language translation of design (PLT)
- ambiguous or inconsistent human-computer interface (HCI)
- miscellaneous (MIS)
 Statistical Quality Assurance
In conjunction with the collection of defect information, software developers can calculate an
error index (EI) for each major step in the software engineering process.

After analysis, design, coding, testing, and release, the following data are collected:

Ei = the total no. of errors uncovered during the ith step in the process.

Si = the no. of serious errors

Mi = the no. of moderate errors

Ti = the no. of minor errors

PS = the size of the product at the ith step.

At each step in the software engineering process, a phase index (PI i ) is computed:

PI i = (Si/Ei) + (Mi/Ei) + (Ti/Ei)

Error index (EI) can be computed as follows:

EI = (PI 1 + 2 PI 2 + 3 PI 3 + iPI I)/PS

 The SQA Plan
The SQA plan provides a road map for introducing software quality assurance.

Figure 8.5 presents an outline for SQA plans by IEEE [IEEE94].

Basic items:
- purpose of plan and its scope
- management
- organization structure, SQA tasks, their placement in the process
- roles and responsibilities related to product quality
- documentation
- project documents, models, technical documents, user documents.
- standards, practices, and conventions
- reviews and audits
- test - test plan and procedure
- problem reporting, and correction actions
- tools
- code control
- media control
- supplier control
- records collection, maintenance, and retention
- training
- risk management
 References

 Mcgraw.Hill.Software_Project_Management_2nd_Edition
 Thanks!
Any Questions
?