Software Quality

(Spring 2024)

06/11/24
 Software quality– IEEE definition

Software quality is:

1.The degree to which a system, component, or process meets specified

requirements.

2.The degree to which a system, component, or process meets customer

or user needs or expectations.

06/11/24
 Software quality assurance vs. Software quality
control
• Quality Control (QC) is a set of activities designed to evaluate the
quality of developed or manufactured product(IEEE,1991)
• Activities whose main objective is the withholding of any product that
does not qualify.

• Quality Assurance (QA) is meant to minimize the costs of quality by

introducing a variety of activities throughout the development process
and maintenance process in order to prevent the causes of errors,
detects them, and corrects them in the early stages of the
development.

06/11/24
 Definition: Software Quality Engineering
Software Quality Engineering:

“ The function of software quality is to assure that quality is built into

the software by performing analysis, investigations on the
requirements, design, code and verification processes and results to
assure that reliability, maintainability, and other quality factors are
met.”
or
“The application of a continuous, systematic, disciplined, quantifiable
approach to the development and maintenance of quality throughout
the whole life cycle of software products and systems; that is, the
application of quality engineering to software”

06/11/24
 Software errors, faults and failures
Software errors:
Sections of the code that are partially or totally incorrect as a result of a
grammatical, logical or other mistake made by a systems analyst, a
programmer, or another member of the software development team.

Software faults
are software errors that cause the incorrect functioning of the software
in general or in specific application.

Software faults become software failures only when they are

“activated”, that is, when a user tries to apply the specific software
section that is faulty. Thus, the root of any software failure is a
Software error.
Do all software faults end with software failures?
06/11/24
 Software errors, faults and failures

06/11/24
Relationships between Software errors, faults and
failures

06/11/24
 Software Defect Origins

• As software errors are the cause of poor software quality, it is important to

investigate the causes of these errors in order to prevent them.

• The causes of software errors can be further classified as follows according

to the stages of the software development process in which they occur.

• Faulty definition of requirements

• Client side mistakes

• Absence of vital requirement
• Incomplete definition of Requirement
• Inclusion of unnecessary requirements

06/11/24
 Software Defect Origins
Client–developer communication failures

Misunderstanding of the
• Client’s instructions as stated in the requirement document
• Client’s requirements changes presented to the developer
• Client’s responses to the design problems presented by the developer.
• Lack of attention to client messages referring to requirements changes

Deviations from software requirements

• Developers may deliberately deviate from the documented requirements

• The developer reuses software modules taken from an earlier project
without sufficient analysis of the changes
• Due to time or budget pressures, the developer decides to omit part of the
required functions

06/11/24
 Software Defect Origins

Logical design errors

• Algorithm mistakes
• Non-compliance with documentation and coding standard
Shortcomings of testing process
• Incomplete test plans leave untreated portions of the software
• Incomplete correction of detected errors due to negligence or time
pressures.
Documentation Errors
• Errors in design document
• Omission of software functions.
• Errors in user manual
• Errors in the explanations and instructions given to users

06/11/24
SQA – Software Life Cycle
 Quality Standards
Quality standards for software engineering:

These are standard written down, that must be followed by software engineers
and engineering firms to achieve quality in their products. Below are some
major standards in the software engineering industry:

1. Capability Maturity Model (CMM):

written by the software engineering institute, this model describes good
practices for planning, engineering and managing software development. This
practice allows software engineering organizations to create quality software
while minimizing budget and time factors. CMM allows software engineers to
judge and compare its processes to stated practices in the industry. Thus
improving software processes and quality.

06/11/24
CMMI Staged Representation - 5 Maturity Levels

Level 5 Process performance

continually improved through
incremental and innovative
Optimizing technological improvements.
Level 4
yit
ur
Processes are controlled using
at
Quantitatively
statistical and other quantitative
M

Managed
techniques.
ss
ce

Level 3
o

Processes are well characterized and

Pr

understood. Processes, standards,

Defined
procedures, tools, etc. are defined at the
Level 2 organizational level.

Managed Processes are planned, documented, performed,

monitored, and controlled at the project level.
Level 1

Initial Processes are unpredictable, poorly controlled.

 Quality Standards

ISO 9000 family: These are standards for quality management and quality
assurance for any business. It applies to process of creating, and controlling
of products and services an organization provides, by giving an organized
course for activities to be carried out to ensure that customer’s requirements
are made (ISOQAR, 2010). This includes the:

•ISO 9000
•ISO 9001
•ISO 9126

06/11/24
 Quality Standards
3. IEEE STD 1061-1998 Standard:

This standard was created as a way to establish quality requirements, and

provides a well defined metrics for identifying, implementing, analyzing and
validating the processes of developing a quality software product. The
standard provides metrics for quality for the entire software engineering life
cycle (IEEE Std 1061, 1998).

06/11/24
Software Quality Assurance and Reviews

• Software development Process  Different documents (SRS+

DDS)

• The system analysts & development team members who

prepared the document will check it repeatedly in order to
detect any possible error that might have entered.

• Others – such as peers, experts, and customer’s representatives–

reviewing the product and detecting the errors unnoticed by the
development team.
 Review Methodologies

Several methodologies can be implemented when reviewing

documents.

• Formal Reviews
• Peer Reviews (inspections and walkthroughs)
• Expert opinions
 Review Methods –Formal reviews

• Formal reviews, variously called …“formal technical

reviews (FTR)”

• Necessary for approval of the product.

• Formal reviews may be conducted at any development

milestone completion of document, whether that
document is a requirement specification , Design
document or an installation plan.
 Formal Reviews

• The participants
• The prior preparations
• The FR session
• The recommended post-FR activities.
 Formal Reviews
The participants in a FR

All FRs are conducted by a review leader and a review team.

The review team:

• A review team of three to five members is expected to be an efficient

team

• Should be selected from among the senior members of the project

team

• Senior professionals assigned to other projects and departments

• Customer–user representatives
• Software development consultants.
 Formal Reviews (FRs)

Preparations for a FR:

The main tasks of the review leader in the preparation stage are:
• To appoint the team members
• To schedule the review sessions
• To distribute the document among the team members (hard copy,
electronic file, etc.).

Review team preparations:

• Review the document

• list their comments prior to the review session.
 Formal Reviews (FRs)

Development team preparations:

• Prepare a short presentation of the document.

• The presentation should focus on the main professional issues awaiting
approval rather than wasting time on description of the project in general

The FR session:

A typical FR session agenda includes:

• A short presentation of the design document.

• Comments made by members of the review team.
• Comments are discussed to determine the required actions (corrections,
changes and additions) that the project team has to perform.
• Decisions about the design product (document), which determines the
project’s progress.
 Formal Reviews (FRs)

These decisions can take three forms:

Full approval
• Enables immediate continuation to the next phase of the project.

Partial approval

• Approval of immediate continuation to the next phase for some parts of the
project, with major action items (corrections, changes and additions)
demanded for the remainder of the project.
• Continuation to the next phase of these remainder parts will be permitted only
after satisfactory completion of the action items.

Denial of approval
• Demands a repeat of the DR. This decision is applied in cases of multiple
major defects, particularly critical defects.
 Formal Reviews

Post-review activities:
• The FR team or its representative is required to follow up performance
of the corrections and to examine the corrected sections.
The FR report
The report’s major sections contain:
• A summary of the review discussions.
• The decision about continuation of the project.
• A full list of the required actions – corrections, changes and additions
that the project team has to perform.
• For each action item, the anticipated completion date and project team
member responsible are listed.
• The name(s) of the review team member(s) assigned to follow up
performance of corrections.
 Peer Reviews:
Inspections / Walkthroughs

• Walkthroughs and inspection differ in formality

• Inspection the more formal of the two

• Inspections emphasize the objective of corrective action

• Walkthroughs limited to comments on document reviewed.

• Inspections are considered to contribute more to SQA.

 Participants of Peer Reviews

Inspection Walkthrough

• Review leader • Review leader

• The author • The author
• Specialized
• Specialized
professionals:
– Designer professionals:
– Coder or implementer – Standards enforcer
– Tester – Maintenance expert
– User representative
 Participants of Peer Reviews

• Review Leader

– Moderator in inspections; Coordinator in walkthroughs.

– Must be well-versed in project development and current

technologies
– Have good relationships with author and development team
– Come from outside the project team
– History of proven experience in coordination / leadership settings
like this.
– For inspections, training as a moderator is required.
 Participants of Peer Reviews

Specialized Professionals

• These differ by review type: inspections / walkthroughs

• Inspections:
Designer – generally the systems analyst responsible for analysis and design of software
system reviewed
coder or implementer – one who is thoroughly acquainted with coding tasks,
preferably the leader of the designated coding team.
• Able to detect defects leading to coding errors and other software implementation
issues.
Tester – experienced professional, preferably leader of assigned testing team.
 Participants of Peer Reviews
Specialized Professionals
• Walkthroughs:

– A standards enforcer – team member specialized in development standards and

procedures
• locate deviations from these standards and procedures.

– A maintenance expert – focus on maintainability / testability issues

• to detect design defects that may hinder bug correction and impact performance
of future changes

• Focuses also on documentation (completeness / correctness) vital for

maintenance activity.
– A user representation
 Participants of Peer Reviews: Team Assignments

• Presenter:
– For inspections:
• The presenter of document; chosen by the moderator; should not be document’s
author
• Sometimes the software coder serves as presenter due to the familiarity of the
design logic and its implications for coding.
– For walkthroughs:
• Author most familiar with the document should be chosen to present it to the
group.
• Could be design document developer; programmer for code
• Some argue that a neutral person should be used..
• Scribe:
– Team leader will often serve as the scribe and record noted defects to be corrected.
 The Peer Review Session

In inspection

• Presenter reads a section of the document.

• As the session progresses, Participants either deliver their comments to the
document or address their reactions to the comments.
• Restrict discussion to identification of errors.

• Presenter in walkthrough provides an overview

• Walkthrough Scribe records each error (location, description, type and

character (incorrect, missing parts, extra parts etc).

• Inspection scribe will add estimated severity of each defect and the formulation
of preventive / corrective actions.
Inspection vs. Walkthrough
Comparison of review methodologies
Comparison of review methodologies
 Expert Opinions
• Expert opinions support quality assessment efforts by introducing additional
external capabilities into the organization's in-house development process

• Turning to outside experts may be particularly useful in the following

situations:

– Insufficient in-house professional capabilities in a given area

– In small organizations: difficult to find enough suitable candidates to
participate in the design review teams
– In small organizations: extreme work pressures, an outside expert’s
opinion can replace an inspection process
– Temporary inaccessibility of in-house professional
– In cases of major disagreement among the organization's senior
professional, an outside expert may support a decision