Lect2 quality factor

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING
CHAPTER 2CHAPTER 2 Software Quality FactorsSoftware Quality Factors
Objectives:
The need for comprehensive requirements
documents
Various types of software quality factors

The need for comprehensive requirements documentsThe need for comprehensive requirements documents
• Cover all attributes of software and aspects of the use
of software
• Help to avoid or reduce poor performance of the
developed software
• To assure the full satisfaction of the users

Various Type of Software Quality FactorsVarious Type of Software Quality Factors
• Software quality factors are the areas which our products will show
risks
• Can put into two categories: internal & external
• Should focus on 3 important aspects
• Software operational characteristics
• Software’s ability to undergo change
• Software’s adaptability to new environment
• There are many quality factors which have been discovered
• Jim McCall’s Quality Factors (1977) – 11 factors
• Boehm’s Quality Factors (1978) – 7 factors
• Evan’s and Marciniak Quality Factors (1987) – 12 factors
• Deutsch and Willis Quality Factors (1988) – 15 factors

Software quality factors
Product operation factors
Product revision factors
Product transition factors

• Correctness
• Reliability
• Efficiency
• Integrity
• Usability
Deal with requirements that directly affect the daily
operation of the software

• Maintainability
• Flexibility
• Testability
Deal with those requirements that affect a complete
range of software maintenance activities

• Portability
• Reusability
• Interoperability
Relate to the adaptation of software to other environments
& its interaction with other software system

Correctness: the functionality matches the specification, defined in a list of the
software system’s required outputs (output specification)
Output specification include:
• The output mission (e.g.: sales invoice output)
• The required accuracy of the outputs (e.g.: the probability for a non-accurate output,
containing one or more mistakes, will not exceed 1%)
• The completeness of the output information (e.g.: the probability of missing data
about a member will not exceed 1%)
• The up-to-datedness of the information (e.g.: the entry information of member
payments and personal data are done not more than one working day)
• The availability of information (e.g.: Reaction time for queries in help desk will be
less than 30 minutes on average)
• The required standards and guidelines (e.g.: user manual are comply with the
client’s guidelines)

Reliability: deal with failures to provide service; determine the maximum
allowed software system failure rate & refer to the entire system or to
one or more of its separate functions.
For example:
• Heart attack detection function is required to have a failure rate of less
than one per million cases
• The Bank Online System will not fail on average more than 10
minutes per month.

Efficiency: deal with the hardware resources needed to perform all the
functions of the software system (including cpu, disk, memory, network &
etc)
For example:
• A chain of stores is considering two alternative bids for a software system.
Both bids consist of placing the same computers in the chain’s headquarters
and its branches. The bids differ solely in the storage volume. Bid A – 20GB
per branch computer & 100GB in the HQ and Bid B- 10 GB per branch &
30GB at the HQ. Bid A requires 3 communication lines but Bid B requires 2
lines. Hence Bid B is more efficient than Bid A because fewer hardware
resources is required.

Integrity: deal with the software system security, protection from
unauthorized access, to distinguish between the majority of personnel
allowed to see the information and a limited group who will be allowed to
add and change data.
For example:
• The Member registration system allows only the manager to access
members’ information & members are allow to access their information
when the username and password match with the first registered username
and encrypted password
• For Bank Online System, transaction to other bank’s account can only be
done when user key in a security number that will send to his/her hand
phone.

Usability: deal with the scope of staff resources needed to
train a new employee and to operate the software system
For example:
• Training a new employee will take no more than two days
and at the end of the training, the employee able to handle
45 service call a day

Maintainability: the ability to find and fix a defect (include identify the
reasons for software failures, correct the failures & to verify the success
of the corrections).
Two aspects of maintainability:
• Serviceability (the probability of returning the item to normal service)
• Reparability (the probability of repairing the actual or impleading
fault)
For example:
• The average time of repair for Bank Online System is 8 minutes
Some examples of maintainability requirements that related to
reliability:
• The size of a software module will not exceed 30 statements
• The programming will adhere to the company coding standards &

Flexibility: the capabilities and efforts required to support
adaptive maintenance activities (include the ability to make
changes required as determined by customer)
For example:
• The teacher support software is suitable for teachers of all
subjects, all school levels and non-professional able to create
new types of reports according to the schoolteachers’
requirements

Testabiltiy: the ability to validate the system requirement
• Tesability that related to software operation: automatic diagnostics
performed by the software system prior to starting the system, to find
out whether all components of the software system are in working order
and to obtain a report about the detected faults
For example:
• An industrial computerized control unit is programmed to calculate
various measure of production status, report the performance level of
the machinery, and operate a warning signal in predefined situations. A
set of standard test data with known system expected correction
reactions is run every morning, to check whether the computerized unit
reacts properly.

Portability: the ability to transfer one software from one
environment to another, the environment could consist of
different hardware, different operating systems etc
For example:
• A software package designed and programmed to operate
in a Windows 2000 environment is required to allow low-
cost transfer to Linux and Windows NT environments

Reusability: the ease of using existing software components (software
modules originally designed for one project) in a different context or a
new software project.
The advantages of reusability:
• Save development resources
• Shorten development period
• Provide higher quality standards
For example:
• Software system for hotel guest and members of a pool club, the reuse
module for another software system for spa might include entrance
validity checks of membership cards and visit recording, restaurant
billing and processing of membership renewal letters

Interoperability: focus on creating interfaces with other software
systems or with other equipment firmware
Interoperability requirements
• can specify the names of the software or firmware for which interface
is required
• can also specify the output structure accepted as standard in a specific
industry or applications area.
For example:
• The firmware of a medical laboratory’s equipment is required to
process its results (output) according to a standard data structure that can
then serve as input for a number of standard laboratory information
systems.

Alternative models ~ Boehm’s Quality Model
• Boehm defined three basic software
requirements:
– As-is utility: the extent to which the as-is
software can be used
– Maintainability: ease of identifying what needs
to be changed as well as ease of modification
and retesting
– Portability: ease of changing software to
accommodate a new environment

• The seven quality factors
• Portability: the extent to which the software will work under
different computer configurations
• Reliability: the extent to which the software performs as required
• Efficiency: optimum use of system resources during correct
execution
• Usability: ease of use
• Testability: ease of validation so that the software meets
requirements
• Understandability: the extent to which the software is easily
comprehended with regard to purpose & structure
• Flexibility: the ease of changing the software to meet revised
requirements
Boehm’s Quality Model

Additional factors from Evans & Marciniak, Deutsch & Willis
• Verifiability (by E & M): define design & programming
features
• Expandability (by E & M, D & W): refer to future efforts
that will be needed to serve larger populations, improve
service, or add new applications in order to improve
usability
• Safety (by D & W): eliminate conditions hazardous to
operators of equipment as a result of errors in process
control software
• Manageability (by D & W): refer to the administrative tools
that support software modification during the software
development & maintenance periods
• Survivability (by D & W): refer to the continuity of service

No. Software quality
factor
McCall’s classic
model
Alternative factor models
Evans and
Marciniak model
Deutsch and
Willis model
1 Correctness + + +
2 Reliability + + +
3 Efficiency + + +
4 Integrity + + +
5 Usability + + +
6 Maintainability + + +
7 Flexibility + + +
8 Testability +
9 Portability + + +
10 Reusability + + +
11 Interoperability + + +
12 Verifiability + +
13 Expandability + +
14 Safety +
15 Manageability +
16 Survivability +

What is reliability?
The probability that software will not cause a system failure for a specified time
under specified conditions. The probability is a function of the inputs to, and
use of, the system as well as function of the existence of faults in the software.
The inputs to the system determine whether existing faults, if any, are
encountered (IEEE)

Characteristics of Software Reliability
•Cannot be defined objectively
Reliability measurements which are quoted out of context are not
meaningful
•Requires operational profile for its definition
defines the expected pattern of software usage
•Must consider fault consequences
Not all faults are equally serious. System is perceived as more
unreliable if there are more serious faults
•Reliability is a dynamic system attribute

The Need of Software Reliability
•Reputation - more reliable product more favorable reputation
•Customer Satisfaction - unreliable product will negatively affect customer satisfaction
severely. Thus high reliability is a mandatory requirement for customer satisfaction.
•Warranty Costs - If a product fails to perform its function within the warranty period, the
replacement and repair costs will negatively affect profits, as well as gain unwanted
negative attention
•Repeat Business – build a good reputation among existing customers
•Cost Analysis - initial cost might be higher, but the overall lifetime cost is lower because
product requires fewer repairs or less maintenance.
•Customer Requirements - customers demand a reliable system
•Competitive Advantage - gain an advantage over competitors who does not publish the
reliability rate or lower failure rate

Errors, Failures & Faults
• ErrorsErrors are human design errors, may not be observed orare human design errors, may not be observed or
detected by usersdetected by users
• AA faultfault is a static software characteristic whichis a static software characteristic which
causes a failure to occur. It is the expression of a softwarecauses a failure to occur. It is the expression of a software
error.error.
• AA failurefailure corresponds to unexpected run-time behaviorcorresponds to unexpected run-time behavior
observed by a user of the softwareobserved by a user of the software
• Faults need not necessarily cause failures. They only do soFaults need not necessarily cause failures. They only do so
if theif the faulty partfaulty part of the software isof the software is usedused

Reliability Improvement
• Reliability is improved when software faults which occur
in the most frequently used parts of the software are
removed
• Removing x% of software faults will not necessarily lead
to an x% reliability improvement
• In a study, removing 60% of software defects actually led
to a 3% reliability improvement
• Removing faults with serious consequences is the most
important objective

Reliability & Efficiency
• As reliability increases system efficiency tends to
decrease
• To make a system more reliable, redundant code
must be included to carry out run-time checks, etc.
This tends to slow it down

• Reliability is usually more important than efficiency
• No need to utilize hardware to the fullest extent as
computers are cheap and fast
• Unreliable software isn't used
• Hard to improve unreliable systems
• Software failure costs often far exceed system
costs
• Costs of data loss are very high
Reliability & Efficiency

The reality
• High costs of reliability achievement
• May be more cost effective to accept unreliability and
pay for failure costs
• Depends on social and political factors
• Depends on system type - for business systems in
particular, moderate reliability may be adequate

Reviews
1. Among the 16 software quality factors, which do you think is the
most important one? Justify your answer(s).
Javab : reliability- tarif- 5,6 morde khososiat
2. Among the 16 software quality factors, which do you think is the
least important one? Justify your answer(s).
Javab :usability we can use skillful person instead of train new
employees.

Case Studies

Lect2 quality factor

More Related Content

What's hot (20)

Similar to Lect2 quality factor (20)

Recently uploaded (20)

Lect2 quality factor

Editor's Notes