Software Quality

MODULE 5
 Contents
o Introduction
o The place of software quality in project planning
o Importance of software quality
o Defining software quality, quality models
o ISO 9126, product and process metrics
o Product versus process quality management
o Quality Management systems, process capability models
o Techniques to enhance software quality
o Testing
o Software reliability
o Quality plans
Introduction
Concept of Quality:
o Generally agreed to be beneficial.
o Often vaguely defined in practice.
o Requires precise definition of required qualities.

Objective Assessment:
o Judging if a system meets quality requirements needs measurement.
 Development Perspective:
o Waiting until the system is complete to measure quality is too late.
o During development, it's important to:
o Assess the likely quality of the final system.
o Ensure development methods will produce the desired quality.
Place of Software Quality in Project
Planning:
Quality will be of concern at all stages of project planning and execution, but will be of
particular interest at the following points in the Step Wise framework shown in fig below:
Step 1: Identify Project Scope and Objectives
o Objectives may include qualities of the application to be delivered.
Step 2: Identify Project Infrastructure
o It involves identifying installation standards and procedures, often related
to quality.
Step 3: Analyze Project Characteristics
o It involves analyzing other project characteristics, including quality-based
ones.
o Example: Safety-critical applications might require additional activities such
as n-version development, where multiple teams develop versions of the
same software to cross-check outputs.
Step 4: Identify the Products and Activities of the Project
o Identify entry, exit, and process requirements for each activity.
Step 8: Review and Publicize Plan
o Review the overall quality aspects of the project plan at this stage.
 Importance of software quality
Quality is a concern of all producers of goods and services. The special characteristics of software
create special demands.

Increasing, criticality of software :The final customer or user naturally anxious about the general
quality of software, especially its reliability. Ex: Safety-critical applications like Control Aircraft.

The intangibility of software can make it difficult to know that a project task was completed
satisfactorily. Task outcomes can be made tangible by demanding that the developer produce
'deliverables‘ that can be examined for quality.

Accumulating errors during software development: As computer system development comprises

For these reasons quality management is an essential part of effective overall project
management.
 Defining Software Quality
A system has functional, quality and resource requirements.
o Functional Requirements: Define what the system is to do.
o Resource Requirements: Specify allowable costs.
o Quality Requirements: State how well the system is to operate.
External and Internal Qualities:
o External Qualities: Reflect the user's view, such as usability.
o Internal Factors: Known to developers, such as well-structured code, which may enhance reliability.
Ex: well-structured code is likely to have fewer errors and thus improve reliability.
Measuring Quality:
o Necessity of Measurement: To judge if a system meets quality requirements, its qualities must be
measurable.
o Good Measure: Relates the number of units to the maximum possible (e.g., faults per thousand lines of code).

o Clarification Through Measurement: Helps to define and communicate what quality really means, effectively
answering "how do we know when we have been successful?"
 Types of Measures:
o Direct Measurement: Measures the quality itself (e.g., faults per thousand
lines of code).
o Indirect Measurement: Measures an indicator of the quality (e.g., number
of user inquiries at a help desk as an indicator of usability).
When project managers identify quality measurements they effectively set
targets for project team members.
Setting Targets:
o Impact on Project Team: Quality measurements set targets for team
members.
o Meaningful Improvement: Ensure that improvements in measured quality
are meaningful.
Example: Counting errors found in program inspections may not be
meaningful if errors are allowed to pass to the inspection stage rather than
being eradicated earlier.
 Drafting a Quality Specification for Software
Products
When there's concern about a specific quality characteristic in a software product, a quality
specification should include the following details:
Definition/Description
o Definition: Clear definition of the quality characteristic.
o Description: Detailed description of what the quality characteristic entails.
Scale
oUnit of Measurement: The unit used to measure the quality characteristic (e.g., faults per
thousand lines of code).
Test
oPractical Test: The method or process used to test the extent to which the quality attribute
exists.
Minimally Acceptable
o Worst Acceptable Value: The lowest acceptable value, below which the
product would be rejected.
Target Range
o Planned Range: The range of values within which it is planned that the
quality measurement value should lie.
Current Value
oNow: The value that applies currently to the quality characteristic.
Measurements Applicable to Quality Characteristics in Software :
When assessing quality characteristics in software, multiple measurements
may be applicable. For example, in the case of reliability, measurements could
include:
1. Availability:
o The percentage of a particular time interval that a system is usable.
2. Mean Time Between Failures (MTBF):
o Definition: Total service time divided by the number of failures.
o Scale: Time (e.g., hours, days).
o Test: Calculate the average time elapsed between system failures.
o Minimally Acceptable: Longer MTBF indicates higher reliability; minimum varies by system
criticality.
o Target Range: E.g., MTBF of 10,000 hours.
3. Failure on Demand:
oDefinition: Probability that a system will not be available when required, or probability that
a transaction will fail.
oScale: Probability (0 to 1).
oTest: Evaluate the system's response to demand or transaction processing.
oMinimally Acceptable: Lower probability of failure is desired; varies by system criticality.
oTarget Range: E.g., Failure on demand probability of less than 0.01.
4. Support Activity:
o Definition: Number of fault reports generated and processed.
o Scale: Count (number of reports).
o Test: Track and analyze the volume and resolution time of fault reports.
o Minimally Acceptable: Lower number of fault reports indicates better reliability.
o Target Range: E.g., Less than 10 fault reports per month.
Maintainability and Related Qualities:
oMaintainability: How quickly a fault can be corrected once detected.
oChangeability: Ease with which software can be modified.
oAnalysability: Ease with which causes of failure can be identified, contributing to
maintainability.
These measurements help quantify and assess the reliability and maintainability of software
systems, ensuring they meet desired quality standards.
 Software Quality Models
The Quality models give characterization of software quality in
terms of a set of characteristics of the software.
The bottom level of hierarchy can be measured directly
and there by can assess the quality of software.
There are well established Quality models including Mc
Call’s Dromey’s and Boehm’s,Then ISO 9126 developed
with stanadardization.
Now We discuss Garvin’s Mc Call’s Dromey’s Boehm’s and
ISO 9126.
 Garvin’s Quality Dimensions
David Garvin A Professor at Harward Business School
defined the quality of any product in terms of eight
attributes of the Product.
Performance How well it performs the job.
Features How well it supports the required features.
Reliability Probability of a product working satisfactorily within a specifc
period of time.
Conformance Degree to which the product meets requirements.
Durability Measure of the Product life
Servicability Speed and effective maintenance
Aesthetics Look and Feel of the system.
Percieved Quality User’s opinion about the quality of the Product
 Mc Call’s Model
MC CALL defined quality in terms of three broad parameters
These three high quality attributes are defined based on eleven attributes of
the software.
 Correcteness The extent to which software product satisfies its specifications.
 Reliability The probability of software product working satisfactorily over a
given duration
 Efficiency The amount of computing resources required to perform the
required functions.
 Integrity The extent to which data
 Usability The effort required to operate the software product
 Maintainability The ease with which it is possible to locate and fix bugs in the
software product.
Flexibility the effort required to operate the software product to
changing requirements
Testability The effort required to test a software quality product to
ensure that it performs it’s intended function.
Portability The effort required to transfer the software product
from one hardware or software system environment to another.
Reusability the extent to which software product can be reused in
other applications.
Interoperability The effort required to integrate the software with
other software.
 Droomey’s Model
Droomy proposed that software product quality depends on
four mazor high level properties of the software.
Correctness,Internal Characteristics,Contextual
Characteristics and certain descriptive Properties.
Each of these hogh level properties in turn depends on lower
level quality attributes of the software.
Droomey’s hierarchial Quality model is shown below.
Droomy’s Quality Model
 Boehm’s model
Boehm proposed that quality Of software can be defined based on
the high level characteristics are
As Is Use Utility How well (easily,reliably,efficiently) can it be used?
Maintainability-How easy is it to understand ,modify and then retest
software?
Portability-How difficult would it be to make the software in a
changed environment?
Boehm expressed these high level product quality attributes in terms
of measurable product attributes.
Boehm’s quality model is based on wide range of software attributes
and with geater focus on software maintainability.
Boehm’s hierarchial quality model is as shown below.
 ISO 9126
ISO 9126 is a significant standard in defining software quality attributes and providing
a framework for assessing them.
The ISO 9l26 standard was first introduced in 1991 to tackle the question of the
definition of software quality.
The original '13-page document was designed as a foundation upon which further,
more detailed, standards could be built.
The ISO 9126 standards documents are now very lengthy. Partly this is because people
with differing motivations might be interested in software quality, namely:
oAcquirers: who are obtaining software from external suppliers;
oDevelopers: who are building a software product;
oIndependent evaluators who are assessing the quality of a software product, not for
themselves but for a community of users - for example, those who might use a
particular type of software tool as part of their professional practice.
ISO 9126 has separate documents to cater for these three sets of needs. Despite
the size of this set of documentation, it relates only to the definition of software
quality attributes.
ISO 9126 also introduces another type of quality - quality in use - for which the
following
Elements have been identified:
o effectiveness; the ability to achieve user goals with accuracy and
completeness;
o productivity: avoiding the excessive use of resources, such as staff effort, in
achieving user goals;
o safety: with reasonable levels of risk of harm to people and other entities such
as business, software, property and the environment;
Satisfaction: smiling users.
'Users' in this context includes not just those who operate the system
containing the software, also those who maintain and enhance the
software.
The idea of quality in use underlines how the required quality of the
software is an attribute not just of the software but also of the context
of use.
ISO 9126 identifies six major external software quality characteristics:
o Functionality: covers the functions that a software product provides to satisfy
user needs;
o Reliability: relates to the capability of the software to maintain its level of
performance;
o Usability: relates to the effort needed to use the software;
o Efficiency: relates to the physical resources used when the software is
executed;
o Maintainability: relates to the effort needed to the make changes to the
software;
o Portability: relates to the ability of the software to be transferred to a
different environment.
ISO 9126 suggests sub-characteristics for each of the primary
characteristics .
 1.Functionality Sub-Characteristics
1. Functionality Compliance: Refers to
the degree to which the software
adheres to application-related
standards or legal requirements,
such as auditing standards.
Example: Ensuring software meets
specific industry regulations or
international standards relevant to its
functionality, reliability, usability,
efficiency, maintainability, and
portability.
2. Interoperability: Refers to the ability
of the software to interact with
other systems effectively.
Maturity refers to the frequency of faults in a software
product.
More the software has been used,More faults have been
uncovered and removed.
Recoverability clearly distinguishes from
Security that control access to a system.
Learnability distinguishes from operability.
A Software tool could be easy to use but time
consuming,to use,as It uses a large nested
menus.
Attractiveness is a recent addition to the sub characteristics
of Usability and is important,when users are not cpmpelled to
use a particular software Product.
Analysability is the ease with which the cause of a failure can be determined.
Changeability is the quality that others call flexibility
Portability compliance relates to those
Standards that have a Bearing on Portability.
The use of a standard Programming Language
common to many software/hardware
environments would be example for this.
ISO 9126 provides guidelines for the use of the quality
characteristics.
Once the requirements of the Software Product have
been established,the following steps are suggested
Once requirements have been established,following steps are
suggested
Judge the Importance of Each Quality Characteristic-reliability for
safety critical systems and Efficiency for some Real time systems.
Select the External Quality characteristic within ISO 9126 framework
needed to qualities prioritized.MTBF is important for Relaibility while
for Efficiency time behaviour and Response time are important.
Map Measurements onto ratings that reflect user satisfaction For
response time For Example it is as shown in table
Identify the relevant internal Measurements and the
Intermediate products in which they appear
This is important when software is being developed and need
to assess the quality of the product during development.
The mappings between internal and external quality
characteristics and measurements are least convincing
element in the approach.The part of the standard give
guidance is a technical report.
According to ISO 9126,measurements act as Indicators of the
final quality of the software at different stages of life cycle.
When potential users are assessing different software product to select best one the
outcome will be along the lines that the Product A is more satisfactory than Product B or
C .One approach recognizes some mandatory quality rating levels,which a Product must
reach or reject.
Objective measurement of some function and relating different measurement values to
different levels of User satisfaction.as in below table
Along with rating for satisfaction,a rating in the range 1-5 could be
assigned to reflect how important each quality characteristic was .
The scores for each quality could be given due weight by multiplying it
by the importance of weighting.
These weighted scores can then be summed up to obtain overall score
for the product.
Overall Assessment of the Product Quality To what extent is it
possible to combine ratings for different quality characteristics into a
single overall rating for the software.
Sometimes presence of one quality may detriment another.
For Example efficiency characteristics of time behaviour and
resource utilization could be enhanced by exploiting particular
characteristic of the operating system and Hardware Environments
in which the software will perform.
 Product And Process Metrics
We know that user assess the quality of Software Product based on
external attributes,whereas Developers assess quality based on
internal attributes during development.
Developers can ensure the quality of Software product based on
measurement of the relevant internal attributes.
The interanal attributes measure some aspects of the Product called
Product or of the development Process called Process metrics .
 Difference B/W Product And Process Metrics
Product Metrics help in measuring the characteristics of the Product being
developed.
Examples of Product metrics and the specified product characteristics that they
measure are the following
The LOC and Function Point Metrics are used to measure size and person in
months metric is used to measure the effort required to develop a product and
time required to develop a Product is measured in Months.
Process Metrics helps to measure how a development process id performing.
Examples of Process Metrics are review effectiveness,Average number of defect
found per hour of inspection,average defect correction time,productivity,average
number of failures detected during testing per LOC and number of latent defects
per line of code in the developed product.
Product V/S Process Quality Management
The System development Process comprises a number of
activities linked to so that the output of one activity is the
input to the next as in Figure.
Errors can enter at any stage of the Process and can be caused
by either defects in a process that when developers make
mistakes in the Logic or by information not passing clearly and
accurately between development stages.
Errors not removed at earlier stages become expensive in later
stages.
Each development step passes before the error is foun d
increases the amount of rework needed.
Errors should be eradicated by careful examination of the deliverables,of each
step before they are passed on .
One way of doing this is the Process requirement for each step.
Entry Requiremnts-to be placed before any activity starts.An example is
comprehensive set of test data
And expected results be prepared and approved before Program testing can
commense.
Implementation Requiremnts-define how the Process is to be conducted.
In Testing Phase,Whenever an error is found and corrected,all test runs must
be repeated,even those that have been found to run correctly.
Exit requirements-have to be fulfilled before an activity is deemed to have
completed.all tests will have to run successfully with no outstanding errors.