SOFTWARE ENGINEERING

Slide Set 07: Software Quality Assurance

Quality
• The American Heritage Dictionary defines quality as
“a characteristic or attribute of something.”
For software, two kinds of quality may be encountered:
• Quality of design encompasses requirements, specifications, and the
design of the system.
• Quality of conformance is an issue focused primarily on
implementation.
• User satisfaction = compliant product + good quality + delivery
within budget and schedule
Software Quality
Software quality can be defined as:
• An effective software process applied in a manner that creates a
useful product that provides measurable value for those who produce
it and those who use it.
Effective Software Process
• An effective software process establishes the infrastructure that
supports any effort at building a high quality software product.
• The management aspects of process create the checks and balances
that help avoid project chaos—a key contributor to poor quality.
• Software engineering practices allow the developer to analyze the
problem and design a solid solution—both critical to building high
quality software.
• Finally, umbrella activities such as change management and technical
reviews have as much to do with quality as any other part of software
engineering practice.
Useful Product
• A useful product delivers the content, functions, and features that the
end-user desires
• But as important, it delivers these assets in a reliable, error free way.
• A useful product always satisfies those requirements that have been
explicitly stated by stakeholders.
• In addition, it satisfies a set of implicit requirements (e.g., ease of use)
that are expected of all high quality software.
Value Adding
• By adding value for both the producer and user of a software product, high
quality software provides benefits for the software organization and the end-user
community.
• The software organization gains added value because high quality software
requires less maintenance effort, fewer bug fixes, and reduced customer support.
• The user community gains added value because the application provides a useful
capability in a way that expedites some business process.
• The end result is:
1. greater software product revenue,
2. better profitability when an application supports a business process, and/or
3. improved availability of information that is crucial for the business.
Quality Dimension
David Garvin [Gar87] suggests that quality should be considered by taking a multidimensional
viewpoint that begins with an assessment of conformance and terminates with a transcendental
(aesthetic) view.
Although Garvin’s eight dimensions of quality were not developed specifically for software, they
can be applied when software quality is considered:
• Performance Quality: Does the software deliver all content, functions, and features that are
specified as part of the requirements model in a way that provides value to the end-user?
• Feature quality: Does the software provide features that surprise and delight first-time end-
users?
• Reliability: Does the software deliver all features and capability without failure? Is it available
when it is needed? Does it deliver functionality that is error free?
• Conformance: Does the software conform to local and external software standards that are
relevant to the application? Does it conform to de facto design and coding conventions? For
example, does the user interface conform to accepted design rules for menu selection or data
input?
• Durability: Can the software be maintained (changed) or corrected
(debugged) without the inadvertent generation of unintended side effects?
Will changes cause the error rate or reliability to degrade with time?
• Serviceability: Can the software be maintained (changed) or corrected
(debugged) in an acceptably short time period. Can support staff acquire all
information they need to make changes or correct defects?
• Aesthetics: Most of us would agree that an aesthetic entity has a certain
elegance, a unique flow, and an obvious “presence” that are hard to
quantify but evident nonetheless.
• Perception: In some situations, you have a set of prejudices that will
influence your perception of quality.
McCall’s Quality Factor
• McCall, Richards, and Walters [McC77] propose a useful
categorization of factors that affect software quality. These software
quality factors, shown in Figure, focus on three important aspects of a
software product:
• its operational characteristics
• its ability to undergo change
• its adaptability to new environments.
• Correctness: The extent to which a program satisfies its specification and fulfills the
customer’s mission objectives.
• Reliability: The extent to which a program can be expected to perform its intended
function with required precision.
• Efficiency: The amount of computing resources and code required by a program to
perform its function.
• Integrity: Extent to which access to software or data by unauthorized persons can be
controlled.
• Usability: Effort required to learn, operate, prepare input for, and interpret output of a
program.
• Maintainability: Effort required to locate and fix an error in a program. [This is a very
limited definition.]
• Flexibility: Effort required to modify an operational program.
• Testability: Effort required to test a program to ensure that it performs its intended
function.
• Portability: Effort required to transfer the program from one hardware and/or software
system environment to another.
• Reusability: Extent to which a program [or parts of a program] can be reused in other
applications—related to the packaging and scope of the functions that the program
performs. Interoperability. Effort required to couple one system to another.
ISO 9126
• The ISO 9126 standard was developed in an attempt to identify the key quality attributes for
computer software.
• The standard identifies six key quality attributes:
• Functionality. The degree to which the software satisfies stated needs as indicated by the
following sub-attributes: suitability, accuracy, interoperability, compliance, and security.
• Reliability. The amount of time that the software is available for use as indicated by the following
sub-attributes: maturity, fault tolerance, recoverability
• Usability. The degree to which the software is easy to use as indicated by the following sub-
attributes: understandability, learnability, operability.
• Efficiency. The degree to which the software makes optimal use of system resources as indicated
by the following sub-attributes: time behavior, resource behavior.
• Maintainability. The ease with which repair may be made to the software as indicated by the
following sub-attributes: analyzability, changeability, stability, testability.
• Portability. The ease with which the software can be transposed from one environment to
another as indicated by the following sub-attributes: adaptability, installability, conformance,
replaceability
Other Views
• The quality dimensions and factors focus on the software as a whole and
can be used as a generic indication of the quality of an application. To
conduct your assessment, you’ll need to address specific, measurable (or at
least, recognizable) attributes of the interface. For example [Bro03]:
• Intuitiveness. The degree to which the interface follows expected usage
patterns so that even a novice can use it without significant training.
• Efficiency. The degree to which operations and information can be located
or initiated.
• Robustness. The degree to which the software handles bad input data or
inappropriate user interaction.
• Richness. The degree to which the interface provides a rich feature set.
Cost Of Quality
• it costs us time and money—too much time and money to get the
level of software quality we really want.
• The cost of quality can be divided into costs associated with
prevention, appraisal, and failure.
• Prevention costs include
• Quality planning • Formal technical reviews • Test equipment • Training

• Internal failure costs include

• rework • repair • failure mode analysis

• External failure costs are

• complaint resolution • product return and • help line support • warranty work
replacement
Assurance
• Assurance is provided by organization management, it means giving a
positive declaration on a product which obtains confidence for the
outcome.

• It gives a security that the product will work without any fault or error
as per the expectations or requests.
Quality Assurance
Quality Assurance ensures that the approaches, techniques, methods
and processes are designed for the projects are implemented correctly.

• Quality assurance activities monitor and verify that the processes

used to manage and create the deliverables have been followed and
are operative.

“Quality Assurance is fundamentally focused on planning and

documenting those processes to assure quality including things such
as quality plans and inspection and test plans”
• Quality Assurance is a proactive process and is Prevention in nature.
• It recognizes flaws in the process.
• Quality Assurance has to complete before Quality Control.
Control
• Control is to test or verify actual results by comparing it with the defined
standards
• Quality Control
• “Quality Control on the other hand is the physical verification that the
product conforms to these planned arrangements by inspection,
measurements.”

• Quality Control is a reactive process and is detection in nature.

• It recognizes the defects.
• Quality Control has to complete after Quality Assurance.
• Many people think QA and QC are same and interchangeable but this
is not true. Both are tightly linked and sometimes it is very difficult to
identify the differences.

• Fact is both are related to each other but they are different in origins.

• QA and QC both are part of Quality Management however QA is

focusing on preventing defect while QC is focusing on identifying the
defect.
Quality Assurance Vs Quality Control
Quality Assurance Quality Control
It is a process which deliberate on QC is a process which deliberates on
providing assurance that quality fulfilling the quality request.
request will be achieved.

A QA aim is to prevent the defect. A QC aim is to identify and improve

the defects.
QA is the technique of managing the QC is method to verify the quality.
quality.
QA does not involve executing the QC always involves executing the
program. program.
All team members are responsible for Testing team is responsible for QC.
QA.
19
Quality Assurance Vs Quality Control
Quality Assurance Quality Control
QA means Planning for doing a QC Means Action for executing the
process. planned process.
Statistical Technique used on QA is Statistical Technique used on QC is
known as Statistical Process Control known as Statistical Quality Control
(SPC.) (SPC.)
QA makes sure you are doing the QC makes sure the results of what
right things. you’ve done are what you expected.
QA Defines standards and QC ensures that the standards are
methodologies to followed in order followed while working on the
to meet the customer requirements. product.
QA is the process to create the QC is the process to verify that
deliverables. deliverables.
QA is responsible for full software QC is responsible for software testing
development life cycle. life cycle.

20
Software Quality Assurance Activities
• Plan an SQA for a project: It is developed during planning and
approved by all stake holders.
• It is done by software engineering team.
• The plan identifies evaluations to be performed ,audit and reviews to be
performed.
• Standard that are applicable to the project
• Procedure for error reporting and tracking.
• Documents to be produced by SQA group.
• Amount of feed back to software project team.

21
• Participate in development of the project software
process description
• Review process description for compliance with
organizational policy, internal software standard, externally
imposed standard and other part of project plan.
• Review software engineering activities to verify
compliance with the defined software process.

• Audit designed software work produce to verify

compliance with those defined as part of software
process.
• SQA group review selected work, identifies, documents and
tracks deviations, verifies that corrections has been made
and periodically reports the results of its work to project
manager.
• Ensure that deviation in software work and work
products are documented and handled according to
a documented procedure.

• Records any non compliance and report to senior

management.
Software Quality Metrics
• Factors assessing software quality come from three distinct points of
view (product operation, product revision, product modification).

• Software quality factors requiring measures include

• Correctness (defects per KLOC)
• Maintainability (mean time to change)
• Integrity (threat and security)
• Usability (easy to learn, easy to use, productivity increase, user attitude)
• Defect removal efficiency (DRE) is a measure of the filtering ability of
the quality assurance and control activities as they are applied
throughout the process framework.

DRE = E / (E + D)
• E = number of errors found before delivery of work product
• D = number of defects found after work product delivery
Six Sigma
• The term “six sigma” is derived from six standard deviations—3.4 instances
(defects) per million occurrences—implying an extremely high quality
standard.
• The Six Sigma methodology defines three core steps:
• Define customer requirements and deliverables and project goals via well-
defined methods of customer communication
• Measure the existing process and its output to determine current quality
performance (collect defect metrics)
• Analyze defect metrics and determine the vital few causes.
• Improve the process by eliminating the root causes of defects.
• Control the process to ensure that future work does not reintroduce the
causes of defects
DMADV
Define-Measure-Analyze-Design-Verify
• Methodology for producing new processes that meet the Six Sigma Quality
levels desired
• Similar to DMAIC, however, we have a design stage here
• DFSS
• Design-For-Six-Sigma
• Using models or prototypes to create designs and ensure they are effective in
meeting goals
• Avoid root cause of defect and meet customer requirement
• Verify: The process model will avoid defect and meet customer
requirements.
DMAIC VS DMADV

Figure 7.2: DMAIC vs DMADV

Software reliability
• Software reliability is defined in statistical terms as
“the probability of failure-free operation of a computer program in a
specified environment for a specified time”.
• A simple measure of reliability is mean-time-between-failure (MTBF),
where
MTBF = MTTF + MTTR
MTTF= mean-time-to-failure
MTTR =mean-time-to-repair
Software availability
• Software availability is
“the probability that a program is operating according to
requirements at a given point in time”

Availability = [MTTF/(MTTF + MTTR)] x 100%

Software Safety
• Identification and assessment of potential hazards that may affect
software negatively and causes entire system to failure.

• If haphazard identified early in software process, software design

feature can be specified that will either eliminate or control potential
hazards.

• Hazards are identified and categorized by criticality and risk.

Example
• Hazards with computer based cruise control for automobile
• Caused uncontrolled acceleration that cant be stopped.
• Does not respond to depression on brakes pedal (turning off).
• Does not engaged when switch is active.
• Slowly loses or gains speed.
• After identification analysis technique to be use to assign severity and
possibility of occurrence.
• Once analysed entire system(subtle user input)and external environment
condition.
• Safety related requirement can be specified for the system
• Specification contain undesirable events and response to these events.
• Software reliability uses statistical analysis to determine the likelihood
that software failure will occur.
• However occurrence of failure does not necessary results in haphazard or mishap.