SOFTWARE QUALITY ASSURANCE AND TESTING

UNIT - V

INTERNAL & EXTERNAL SOFTWARE PRODUCTS MEASUREMENT

❖ DIRECT & INDIRECT MEASUREMENTS: -

A) Direct measures of a software engineering process include cost and effort.

Direct measures of the product include lines of code (LOC), execution speed, memory
size, defects reported over some time period.

B) Indirect product measures examine the quality of the software product itself (e.g.,
functionality, complexity, efficiency, reliability, maintainability).

❖ SOFTWARE SIZE COMPONENTS INCLUDES: -

1) Length (code, specification, design)

2) Reuse (Reuse-based software engineering)

3) Functionality (function point, feature point, object point, use-case point)

4) Complexity

Internal product attributes describe a software product in a way that is dependent only
on the product itself.

a. One of the most useful attributes is the size of a software product, which can be
measured statically, i.e., without executing the system.
b. It is necessary to define software size in terms of more than one internal attribute,
each capturing a key aspect of software size.
c. Size measurement must reflect effort, cost and productivity.

1) Length

I) Length is the “physical size” of the product.

II) In a software development effort, there are three major development products:
specification, design, and code.
III) The length of the specification can indicate how long the design is likely to be, which
in turn is a predictor of code length.

IV) Traditionally, code length refers to text-based code length.

A) Code - LOC

I) The most commonly used measure of source code program length is the number of
lines of code (LOC).

II) NCLOC: non-commented source line of code or effective lines of code (ELOC).

III) CLOC: commented source line of code.

IV) By measuring NCLOC and CLOC separately we can define:

total length (LOC) = NCLOC + CLOC

V) The ratio: CLOC/LOC measures the density of comments in a program.

LOC variations:

• Count of physical lines including blank lines.

• Count of all lines except blank lines and comments.
• Count of all statements except comments (statements taking more than one line
count as only one line).
• Count of all lines except blank lines, comments, declarations and headings.
• Count of only executable statements, not including exception conditions.

B) Specification and design

Spec. & Design Specification and design documents are usually composed of logical
text (axioms, constraints, etc.) and diagrams (flow graphs, etc.) Define atomic objects to
measure textual contents and graphical contents

2) Reuse

In most engineering disciplines, systems are designed by composing existing

components that have been used in other systems.

● Software engineering has been more focused on original development but it is now
recognised that to achieve better software, more quickly and at lower cost, we need to
adopt a design process that is based on systematic software reuse.
2) Reuse-based software engineering

a) Application system reuse

• The whole of an application system may be reused either by incorporating it without

change into other systems (COTS reuse) or by developing application families.

b) Component reuse

• Components of an application from sub-systems to single objects may be reused.

c) Object and function reuse

• Software components that implement a single well-defined object or function may be

reused.

Advantages of Reuse:

a) Increased dependability

● Reused software, that has been tried and tested in working systems, should be more
dependable than new software.

● The initial use of the software reveals any design and implementation faults. These
are then fixed, thus reducing the number of failures when the software is reused.

b) Reduced process risk

● If software exists, there is less uncertainty in the costs of reusing that software than
in the costs of development.

● This is an important factor for project management as it reduces the margin of error
in project cost estimation.

● This is particularly true when relatively large software components such as sub-
systems are reused.

c) Effective use of specialists

●Instead of application specialists doing the same work on different projects, these
specialists can develop reusable software that encapsulate their knowledge.
d) Accelerated development

● Bringing a system to market as early as possible is often more important than overall
development costs.

● Reusing software can speed up system production because both development and
validation time should be reduced.

Disadvantages of Reuse

a) Increased maintenance costs

● If the source code of a reused software system or component is not available then
maintenance costs may be increased as the reused elements of the system may become
increasingly incompatible with system changes.

b) Lack of tool support

● CASE tool sets may not support development with reuse. It may be difficult or
impossible to integrate these tools with a component library system.

●The software process assumed by these tools may not take reuse into account.

c) Creating and maintaining a component library

● Populating a reusable component library and ensuring the software developers can
use this library can be expensive.

● Our current techniques for classifying, cataloguing and retrieving software

components are immature.

3) Functionality

The amount of functionality inherent in a product gives the measure of product size.
There are so many different methods to measure the functionality of software products.

a) Function point

● Function point metrics provide a standardized method for measuring the various
functions of a software application.

● It measures the functionality from the user’s point of view, that is, on the basis of
what the user requests and receives in return.

● Function point analysis is a standard method for measuring software development

from the user's point of view.
● Function Point (FP) is a weighted measure of software functionality. ¡ FP is computed
in two steps:

1) Calculating Unadjusted Function Point Count (UFC).

2) Multiplying the UFC by a Value Adjustment Factor (VAF) ¡

The final (adjusted) Function Point is:

FP = UFC × VAF

b) Feature Points

● Feature point is the superset of function point measure that can be applied to systems
and engineering software applications.

● The feature points are used in those applications in which the algorithmic complexity
is high like real-time systems where time constraints are there, embedded systems, etc.

c) object point

● It measures the size of an application by counting the no of screens, reports &

interfaces (Known as object) required completing the coding.

● The Objects themselves can be classified into different level of complexity such as
simple, average &complex.

● The object point method requires the design phase of the software development life
cycle. Then only we can assume the screens & reports of the project.

● The effort estimated for objects is similar to that of SLOC and it’s focused on the code
and test phase of the project execution life cycle.

Effort=app size*Complexity*Productivity rate

d) Use-Case Points

● A Use-Case is a series of related interactions between a user and a system that enables
the user to achieve a goal.

● Use-Cases are a way to capture functional requirements of a system. The user of the
system is referred to as an ‘Actor’. Use-Cases are fundamentally in text form.

● Use-Case Points is a software estimation technique used to measure the software size
with use cases.
The number of UCPs in a project is based on the following –

1) The number and complexity of the use cases in the system.

2) The number and complexity of the actors on the system.

▪ Various non-functional requirements such as portability, performance,

maintainability that are not written as use cases.
▪ The environment in which the project will be developed such as the language,
the team’s motivation, etc.

Use-Case Points Counting Process-

1. Calculate unadjusted UCPs Adjust for technical complexity

2. Adjust for environmental complexity
3. Calculate adjusted UCPs

Step: - Calculate Unadjusted Use-Case Points.

You calculate Unadjusted Use-Case Points first, by the following steps –

1. Determine Unadjusted Use-Case Weight Determine

2. Unadjusted Actor Weight
3. Calculate Unadjusted Use-Case Points

Calculate Adjusted Use-Case Points (UCP) as − UCP = UUCP × TCF × EF

Advantages of Use-Case Points

• UCPs are based on use cases and can be measured very early in the project life
cycle.
• UCP will be independent of the size, skill, and experience of the team that
implements the project.
• UCP based estimates are found to be close to actuals when estimation is
performed by experienced people.

Disadvantages of Use-Case Points

• UCP can be used only when requirements are written in the form of use cases.
• Dependent on goal-oriented, well-written use cases. If the use cases are not well or
uniformly structured, the resulting UCP may not be accurate.
3) Complexity

Complexity is a separate component of size.

a) Complexity of a problem − It is the number of resources required for an optimal

solution to the problem.
b) Complexity of a solution − It is the resources needed to implement a particular
solution. It has two aspects. They are as follows −
c) Time complexity − The resource is computer time.
d) Space complexity − The resource is computer memory.

❖ SOFTWARE QUALITY

● Software Quality model is a vital to obtained data so that actions can be taken to
improve the performance. Such improvement can be measured quality, increased
customer satisfaction and decreased cost of quality.

● Software metrics and quality models play a pivotal role in measurement of software
quality.

A) External quality

● External quality is the totality of characteristics of the software product from an

external view.

● It is the quality when the software is executed, which is typically measured and
evaluated while testing in a simulated environment with simulated data using external
metrics. During testing, most faults should be discovered and eliminated.

● However, some faults may still remain after testing. As it is difficult to correct the
software architecture or other fundamental design aspects of the software, the
fundamental design remains unchanged throughout the testing.

B) Internal Quality

● Internal quality is the totality of characteristics of the software product from an

internal view.

● Internal quality is measured and evaluated against the Internal Quality requirements.
 ● Details of software product quality can be improved during code implementation,
reviewing and testing, but the fundamental nature of the software product quality
represented by the Internal Quality remains unchanged unless redesigned.

❖ SOFTWARE QUALITY MODELS

1) McCall software Quality Model

● One of the more renown predecessors of today’s quality models is the quality model
presented by Jim McCall (also known as the General Electric’s Model of 1977).

● McCall’s quality model defines and identifies the quality of a software product through
addressing three perspectives:

• Product operation
is the product’s ability to be quickly understood, operated and capable of providing the
results required by the user. It covers correctness, reliability, efficiency, integrity and
usability criteria.

• Product revision
is the ability to undergo changes, including error correction and system adaptation. It
covers maintainability, flexibility and testability criteria.

• Product transition
is the adaptability to new environments, distributed processing together with rapidly
changing hardware. It covers portability, reusability and interoperability criteria.

2) Boehm’s Software Quality Model

● Boehm introduced his quality model to automatically and quantitatively evaluate the
quality of software.

● Boehm’s quality model represents a hierarchical structure of characteristics, each of

which contributes to the total quality.

● The model begins with the software’s general utility, i.e., the high-level characteristics
that represent basic high-level requirements of actual use.

● The general utility is refined into a set of factors and each factor is composed of several
criteria which contribute to it in a structured manner. The factors include:
a. portability utility which is further refined into reliability, efficiency and human
engineering.
b. maintainability which is further refined into testability, understandability and
modifiability.

3) Dromey’s Software Quality Model

● Dromey’s proposes a working framework for evaluating Requirement determination,

design and implementation phases.

● The framework consists of three models, i.e. Requirement quality model, Design
quality model and Implementation quality model.

The high-level product properties for the implementation quality model include:

a) Correctness evaluates if some basic principles are violated, with functionality and
reliability as software quality attributes.
b) Internal measures how well a component has been deployed according to its
intended use, with maintainability, efficiency and reliability as software quality
attributes.
c) Contextual deals with the external influences on the use of a component, with
software quality attributes in maintainability, reusability, portability and
reliability.

d) Descriptive measures the descriptiveness of a component, with software quality

attributes in maintainability, reusability, portability and usability.

4) FURPS Software Quality Model

The characteristics that are taken into consideration in FURPS model are:

a) Functionality includes feature sets, capabilities and security.

b) Usability includes human factors, consistency in the user interface, online and
context-sensitive help, wizards, user documentation, and training materials.
c) Reliability includes frequency and severity of failure, recoverability, predictability,
accuracy, and mean time between failure (MTBF).
d) Performance prescribes conditions on functional requirements such as speed,
efficiency, availability, accuracy, throughput, response time, recovery time, and
resource usage.
e) Supportability includes testability, extensibility, adaptability, maintainability,
compatibility, Configurability, serviceability, installability, and localizability /
internationalization.

5) ISO 9126 Software Quality Model

● ISO 9126 is an international standard for the evolution of software. The standard is
divided into four parts which address respectively the following subjects: Quality model,
External metrics, internal metrics and quality in use metrics.

● The model follows the factor-criteria-metric model and categorizes software quality
attributes into six independent high-level quality characteristics: functionality,
reliability, usability, efficiency, maintainability and portability.

● Each of these is broken down into secondary quality attributes, e.g., maintainability
is refined into analysability, changeability, stability, testability and compliance to
standards, conventions or regulations.

● One may also argue if the enhancement-with-new features type of change is embedded
within the types of modifications defined in the quality model, i.e. corrections,
improvements or adaptations of the software to changes in environment, requirements
and functional specifications.

ISO 9126 Quality Factors

The ISO 9126 standard identifies six key quality attributes.

1) Functionality - degree to which software satisfies stated needs.

2) Reliability - the amount of time the software is up and running.
3) Usability - the degree to which software is easy to use.
4) Efficiency - the degree to which software makes an optimum utilization of the
resources.
5) Maintainability - the ease with which the software can be modified.
6) Portability - the ease with which software can be migrated from one environment
to the other.

Each quality factors and its corresponding sub-factors are defined as follows:

1) Functionality: A set of attributes that relate to the existence of a set of functions

and their specified properties. The functions are those that satisfy stated or implied
needs.
2) Suitability: Attribute of software that relates to the presence and appropriateness
of a set of functions for specified tasks.
3) Accuracy: Attributes of software that bare on the provision of right or agreed results
or effects.
4) Security: Attributes of software that relate to its ability to prevent unauthorized
access, whether accidental or deliberate, to programs and data.
5) Interoperability: Attributes of software that relate to its ability to interact with
specified systems.
6) Fault tolerance: Attributes of software that relate to its ability to maintain a
specified level of performance in cases of software faults or of infringement of its
specified interface.
7) Recoverability: Attributes of software that relate to the capability to re-establish its
level of performance and recover the data directly affected in case of a failure and on
the time and effort needed for it.
8) Operability: Attributes of software that relate to the users' effort for operation and
operation control.
9) Efficiency: A set of attributes that relate to the relationship between the level of
performance of the software and the number of resources used, under stated
conditions.
10) Time behaviour: Attributes of software that relate to response and processing.