Software Quality

Faculty of Computer Science and Engineering
Software Engineering
Software Quality
FACULTY OF COMPUTER
SCIENCE AND ENGINEERING
Topics covered
◼ Infamous software bugs
◼ To introduce ethical and professional issues
and to explain why they are of concern to
software engineers
◼ Standards for evaluation of software quality
2
FACULTY OF COMPUTER
Software bugs
◼ A software bug is any problem that triggers a
program to crash or produce invalid output.
◼ The problem is caused by insufficient or
erroneous logic.
◼ A bug can be an error, mistake, defect or fault,
which may cause failure or deviation from
expected results.
◼ Most bugs are due to human errors in source
code or its design.
3
FACULTY OF COMPUTER
Infamous software bugs (1)

◼ 1962: a bug in the flight software for the
Mariner I spacecraft caused the rocket to
change path from the expected path
◼ 1980s: bugs in the code controlling the
machine called Therac-25, used for radiation
therapy, lead to patient deaths
◼ 1990s: a bug was found in the new release of
AT&T’s software control #4ESS long distance
switches caused many computers to crash
4
FACULTY OF COMPUTER
Infamous software bugs (2)

◼ 1991: the Patriot Missile failed to track and
intercept an incoming Iraqi Scud missile
◼ 1996: a rocket Ariane 5 was destroyed a few
seconds after launch due to a bug in the on-
board guidance computer program
◼ 2000: Y2K, a problem in the coding of
computerized systems that was projected to
create havoc in computers and computer
networks at the beginning of the year 2000
5
FACULTY OF COMPUTER
Mariner I software bug

◼ One of the most expensive software bugs:
18.5 million US$, current value, equals 158
million US$ in 2020.
◼ An incorrectly encoded punch card helped to
doom the Mariner 1 spacecraft.
◼ Incorrect commands couldn’t be caught by
simply looking at what was typed on a screen.
6
FACULTY OF COMPUTER
Therac-25
◼ Between June 1985 and January 1987, a
software-controlled radiation therapy
machine called the Therac-25 massively
overdosed six people, resulting in serious
injury and deaths.
◼ It wasn’t an anomaly but simply the first of
many, as these types of radiation-overdose
accidents continue today.
7
FACULTY OF COMPUTER
AT&T’s Long-Distance Network Upgrade
◼ An estimated loss of 60 US$ million in long-

distance charges, current value: 120 million
US$.
◼ 9 hours of service time, approximately 75
million missed phone calls, and an estimated
loss of 200,000 airline reservations.
◼ A minor mechanical problem sent out a
congestion signal (basically a “do not disturb”
message) to switches it was linked to.
8
FACULTY OF COMPUTER
The Patriot Missile failure

◼ The Scud struck an American Army barracks,
killing 28 soldiers and injuring around 100
other people.
◼ The cause was an inaccurate calculation of
the time since boot due to computer
arithmetic errors.
◼ The time in tenths of second as measured by
the system's internal clock was multiplied by
1/10 to produce the time in seconds
9
FACULTY OF COMPUTER
The explosion of Ariane 5

◼ On June 4, 1996 an unmanned Ariane 5 rocket
launched by the European Space Agency exploded
just forty seconds after its lift-off from Kourou,
French Guiana.
◼ The rocket was on its first voyage, after a decade of
development costing 7 billion US$, current value:
14.5 billion US$.
◼ A 64-bit floating-point number relating to the
horizontal velocity of the rocket with respect to the
platform was converted to a 16-bit signed integer.
10
FACULTY OF COMPUTER
Y2K bug / glitch

◼ Y2K is also called a Millennium bug.
◼ The Y2K bug was a computer flaw, or bug, that may
have caused problems when dealing with dates
beyond December 31, 1999.
◼ When complex computer programs were first
written in the 1960s, engineers used a two-digit code
for the year, leaving out the "19.“
◼ As the year 2000 approached, many believed that
the systems would not interpret the "00" correctly,
therefore causing a major glitch in the system.
11
FACULTY OF COMPUTER
Professional and ethical responsibility
◼ Software engineering involves wider

responsibilities than simply the application of
technical skills.
◼ Software engineers must behave in an honest
and ethically responsible way if they are to be
respected as professionals.
◼ Ethical behaviour is more than simply
upholding the law.
16
FACULTY OF COMPUTER
Issues of professional responsibility

◼ Confidentiality
 Engineers should normally respect the
confidentiality of their employers or clients
irrespective of whether or not a formal
confidentiality agreement has been signed.
◼ Competence
 Engineers should not misrepresent their level of
competence. They should not knowingly accept
work which is outwith their competence.
17
FACULTY OF COMPUTER
Issues of professional responsibility

◼ Intellectual property rights
 Engineers should be aware of local laws governing the use
of intellectual property such as patents, copyright, etc.
They should be careful to ensure that the intellectual
property of employers and clients is protected.
◼ Computer misuse
 Software engineers should not use their technical skills to
misuse other people’s computers. Computer misuse
ranges from relatively trivial (game playing on an
employer’s machine, say) to extremely serious
(dissemination of viruses).
18
FACULTY OF COMPUTER
First ethical codices

◼ In 1977, Don Parker defined almost fifty hypothetical
examples of computer misuse
◼ Don Parker, Deborah Johnson and ACM’s working
body: first accredited ethical codex of computer
ethics
◼ IEEE publishes its own codex of computer ethics
◼ Code of honor (ethical codex) of MASIT
19
FACULTY OF COMPUTER
ACM/IEEE Code of Ethics

◼ The professional societies in the US have cooperated
to produce a code of ethical practice.
◼ Members of these organisations sign up to the code
of practice when they join.
◼ The Code contains eight Principles related to the
behaviour of and decisions made by professional
software engineers, including practitioners,
educators, managers, supervisors and policy makers,
as well as trainees and students of the profession.
20
FACULTY OF COMPUTER
Code of ethics – preamble (1)

◼ The short version of the code summarizes
aspirations at a high level of the abstraction; the
clauses that are included in the full version give
examples and details of how these aspirations
change the way we act as software engineering
professionals. Without the aspirations, the details
can become legalistic and tedious; without the
details, the aspirations can become high sounding
but empty; together, the aspirations and the details
form a cohesive code.
21
FACULTY OF COMPUTER
Code of ethics – preamble (2)

◼ Software engineers shall commit themselves to
making the analysis, specification, design,
development, testing and maintenance of software a
beneficial and respected profession. In accordance
with their commitment to the health, safety and
welfare of the public, software engineers shall
adhere to the following Eight Principles:
22
FACULTY OF COMPUTER
Code of ethics - principles

◼ PUBLIC
 Software engineers shall act consistently with the public interest.
◼ CLIENT AND EMPLOYER
 Software engineers shall act in a manner that is in the best interests of
their client and employer consistent with the public interest.
◼ PRODUCT
 Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
23
FACULTY OF COMPUTER

◼ JUDGMENT
 Software engineers shall maintain integrity and independence in their
professional judgment.
◼ MANAGEMENT
 Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software
development and maintenance.
◼ PROFESSION
 Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.
24
FACULTY OF COMPUTER

◼ COLLEAGUES
 Software engineers shall be fair to and supportive of their
colleagues.
◼ SELF
 Software engineers shall participate in lifelong learning
regarding the practice of their profession and shall
promote an ethical approach to the practice of the
profession.
25
FACULTY OF COMPUTER
ACM: Code of Ethics (the preamble)

◼ Contribute to society and human well-being.
◼ Avoid harm to others.
◼ Be honest and trustworthy.
◼ Be fair and take action not to discriminate.
◼ Honor property rights including copyrights and
patent.
◼ Give proper credit for intellectual property.
◼ Respect the privacy of others.
◼ Honor confidentiality.
26
FACULTY OF COMPUTER
Ethical dilemmas
◼ Disagreement in principle with the policies of
senior management.
◼ Your employer acts in an unethical way and
releases a safety-critical system without
finishing the testing of the system.
◼ Participation in the development of military
weapons systems or nuclear systems.
27
FACULTY OF COMPUTER
Code of Ethics
◼ NSPE Code of Ethics for Engineers
http://www.nspe.org/ethics/eh1-code.asp
◼ Software Engineering Code of Ethics and
Professional Practice
http://www.acm.org/serving/se/code.htm
28
FACULTY OF COMPUTER
Standardization (1)
◼ Standardization is the process of developing
and implementing technical standards.
◼ The process establishes common agreement
for engineering criteria, terms, principles,
practices, materials, items, processes, and
equipment parts and components.
29
FACULTY OF COMPUTER
Standardization (2)
◼ An organization can benefit from
standardization because it:
 Enables mass production
 Enables customization
 Improves supplier coordination
 Improves quality
 Enables simplification
 Enables delayed differentiation
 Lowers inventories
30
FACULTY OF COMPUTER
Quality criteria for software products

... Correctness
Costs Reliability
Testability Robustness
Compatibility Efficiency
Portability
SW - Quality User-
friendliness
Modularity Maintainability
Reusability Scalability
Readability
FACULTY OF COMPUTER
Correctness
◼ Correctness: the adherence to the
specifications that determine how users can
interact with the software and how the
software should behave when it is used
correctly.
◼ Problem: A software product is correct,
however, fails to achieve what the customer
imagined.
32
FACULTY OF COMPUTER
Reliability
◼ Software reliability is the ‘probability that the
software will execute for a particular period of time
without failure, weighted by the cost to the user of
each failure encountered’.
◼ Reliability models estimate the number of software
failures after development, based on failures
encountered during testing and operation.
◼ Problem: Software reliability is not a function of
operational time.
33
FACULTY OF COMPUTER
Curve for software reliability
34
FACULTY OF COMPUTER
Robustness
◼ Robustness is the ability of a computer system to
cope with errors during execution and cope with
erroneous input.
◼ Software is robust if it can tolerate such problems as
anticipated events, invalid inputs, corrupted
internally stored data, improper uses by system
operators, unavailable databases, stress overloads
and so on.
◼ Problems: equipment damage, loss of power,
software crashes and so on.
35
FACULTY OF COMPUTER
User-friendliness
◼ User-friendly software interfaces are easy to use, i.e.
it is not difficult to learn them or understand.
◼ While "user-friendly" is a subjective term, the
following are several common attributes found in
user-friendly interfaces:
 Simple: straightforward, providing quick access to
common features or commands
 Clean: easy to locate different tools and options
 Intuitive: requires minimal explanation for how to use it
 Reliable: does not malfunction or crash
36
FACULTY OF COMPUTER
Scalability
◼ Scalability in software engineering refers to
designing software systems in such a manner
that, as the number of users of the system
increases (even by factors of 100x or more),
the software will continue to function with
comparable response times.
◼ Problem: whenever web application is being
used by more and more users, the backend
will start to fall apart.
37
FACULTY OF COMPUTER
Improving scalability
38
FACULTY OF COMPUTER
Portability
◼ Being able to move software from one machine
platform to another.
◼ It refers to system software or application software
that can be recompiled for a different platform or to
software that is available for two or more different
platforms.
◼ Problem: the software depends upon its detailed
hardware, software, and setup, with device drivers
for particular devices, using installed operating
system and supporting software components, and
using different drives or directories.
39
FACULTY OF COMPUTER
Cloud application portability

◼ Layers of platform as a service
◼ Need, levels and advantages of application
portability
◼ Areas of challenge in application portability
 Programming language and framework
 Platform-specific services
 Data store
 Platform-specific configuration files
◼ Industry perspective in cloud portability

◼ Analysis and discussion
40
FACULTY OF COMPUTER
Maintainability
◼ Software maintainability is defined as the
degree to which an application is understood,
repaired, or enhanced.
◼ Understanding software maintainability
allows organizations to identify improvement
areas as well as determine the value supplied
by current applications or during
development changes.
41
FACULTY OF COMPUTER
Major maintainability issues

◼ Poor Code Quality
◼ Source Code Defects
◼ Undetected Vulnerabilities
◼ Excessive Technical Complexity
◼ Large Systems
◼ Poorly Documented Systems
◼ Excessive Dead Code
42
FACULTY OF COMPUTER
Classification of quality criteria

◼ Internal and external.
◼ The internal quality factors can only be
perceived by computer professionals.
◼ The external quality factors are ultimately the
relevant ones, as they are perceived by the
user.
43
FACULTY OF COMPUTER
Importance of quality factors

◼ Internal quality determines your ability to
move forward on a project.
◼ External quality determines the fulfillment of
stakeholder requirements.
◼ The external quality factors depend on the
internal quality factors.
44
FACULTY OF COMPUTER
Internal Quality Characteristics

◼ Maintainability
◼ Flexibility
◼ Portability
◼ Re-usability
◼ Readability
◼ Testability
◼ Understandability
45
FACULTY OF COMPUTER
External Quality Characteristics

◼ Correctness
◼ Usability
◼ Efficiency
◼ Scalability
◼ Reliability
◼ Integrity
◼ Adaptability
◼ Accuracy
◼ Robustness
46
FACULTY OF COMPUTER
External and internal quality
47
FACULTY OF COMPUTER
Different viewpoints of software quality

Purchaser
does what I expect
quick
easy to use
offers the desired functionality
cheap in the achievement no built-in errors
needs little memory easy to master
quick does not interrupt
enhances the productivity of the operation good manuals
fulfills its tasks continuously and correctly
low maintenance costs
applicable in more aspects well documented
not many errors User
errors quickly to locate
reliable
relatively easy to alter
readable code
quick to get used to
easy to enhance
Maintenance engineer
FACULTY OF COMPUTER
Internal and external quality criteria

Purchaser
User-
friendliness
Efficiency
Robustness
Reliability
Correctness
Maintainability
User
internal quality criteria

Maintenance engineer external quality criteria
FACULTY OF COMPUTER
Software quality assurance

◼ Software quality assurance (SQA) is a process
which assures that all software engineering
processes, methods, activities and work
items are monitored and comply against the
defined standards.
◼ These defined standards could be one or a
combination of any like maturity models, ISO
9000, ISO90003, ISO15504 and ISO25010.
50
FACULTY OF COMPUTER
Maturity models
◼ OPM3®
◼ Prince (P2MM)
◼ Trillium Model
◼ Capability Maturity Model Integration (CMMI)
51
FACULTY OF COMPUTER
OPM3® maturity model

◼ Organizational Project Management Maturity
Model (OPM3®) – Third Edition
◼ Global standard that provides the tools
organizations need to measure their maturity
against a comprehensive set of organizational
best practices.
◼ It comprises a five-step iterative cycle that
emphasizes assessment and continuous
improvement.
52
FACULTY OF COMPUTER
Prince maturity model (P2MM)

◼ Standard which provides a framework with which
organizations can assess their current adoption of
the PRINCE2 project management method and put in
place improvement plans with measurable
outcomes based on industry best practice.
◼ Enables organizations to gauge, by assessment, their
maturity in the use of PRINCE2
◼ Provide a focus for improvement
◼ Provide verified evidence of maturity at three levels
53
FACULTY OF COMPUTER
Trillium Model
◼ Intended to provide a means to initiate and
guide a continuous improvement program:
 to benchmark an organization's product
development and support process capability
against best practices in the industry,
 in self-assessment mode, to help identify
opportunities for improvement within a product
development organization, and
 in pre-contractual negotiations, to assist in
selecting a supplier.
54
FACULTY OF COMPUTER
Capability Maturity Model Integration

◼ CMMI is a process and behavioral model that helps
organizations streamline process improvement and
encourage productive, efficient behaviors that
decrease risks in software, product and service
development.
◼ The CMMI was developed by the Software
Engineering Institute at Carnegie Mellon University.
◼ The DoD and U.S. Government helped develop the
CMMI, which is a common requirement for DoD and
U.S. Government software development contracts.
55
FACULTY OF COMPUTER
CMMI Maturity Levels

◼ Initial: Work gets completed but it’s often delayed and over
budget.
◼ Managed: Projects are planned, performed, measured and
controlled at this level, but there are still a lot of issues to
address.
◼ Defined: There’s a set of organization-wide standards to
provide guidance across projects, programs and portfolios.
◼ Quantitatively managed: The organization is working off
quantitative data to determine predictable processes that
align with stakeholder needs.
◼ Optimizing: An organization will be in constant state of
improving and responding to changes or other opportunities.
56
FACULTY OF COMPUTER
Future of CMMI V2.0

◼ Focus on performance
◼ Integrated agile with Scrum, safety and
security
◼ Value-added appraisals
◼ Easier to use and assess
57
FACULTY OF COMPUTER
ISO 9000 family

◼ The ISO 9000 family addresses various aspects
of quality management and contains some of
ISO’s best-known standards.
◼ The standards provide guidance and tools for
companies and organizations who want to
ensure that their products and services
consistently meet customer’s requirements,
and that quality is consistently improved.
58
FACULTY OF COMPUTER
ISO/IEC 90003: 2014

◼ ISO/IEC 90003:2014 provides guidance for
organizations in the application of ISO
9001:2008 to the acquisition, supply,
development, operation and maintenance of
computer software and related support
services.
59
FACULTY OF COMPUTER
Application of ISO/IEC 90003:2014

◼ Appropriate to software that is:
 Part of a commercial contract with another
organization,
 A product available for a market sector,
 Used to support the processes of an organization,
 Embedded in a hardware product, or
 Related to software services.
60
FACULTY OF COMPUTER
ISO/IEC 15504-5:2012
◼ Responsible for Software Process
Improvement and Capability Determination
(SPICE)
◼ Set of technical standards documents for the
computer software development process and
related business management functions
◼ The ISO/IEC 15504-5 contains a set of
indicators to be considered when interpreting
the intent of the Process Reference Model.
61
FACULTY OF COMPUTER
ISO 25010
◼ Responsible for:
 Systems and software engineering
 Systems and Software Quality Requirements and
Evaluation (SQuaRE)
 System and software quality models
62
FACULTY OF COMPUTER
Overview of ISO 25010

◼ Part of the SQuaRE series, which consists of
the following divisions:
 Quality Management Division (ISO/IEC 2500n),
 Quality Model Division (ISO/IEC 2501n),
 Quality Measurement Division (ISO/IEC 2502n),
 Quality Requirements Division (ISO/IEC 2503n),
 Quality Evaluation Division (ISO/IEC 2504n),
 SQuaRE Extension Division (ISO/IEC 25050 –
ISO/IEC 25099).
63
FACULTY OF COMPUTER
Critical Systems
◼ Many activities are replaced by computer systems.
◼ Their failure or malfunction may result in one (or
more) of the following outcomes:
 death or serious injury to people
 loss or severe damage to equipment/property
 environmental harm
 serious impact on business operations
 loss of business or damage to reputation
 loss of sensitive data through theft
◼ Therefore, these systems are called critical systems.
64
FACULTY OF COMPUTER
Critical Systems
◼ A critical system is distinguished by the
consequences associated with system or
function failure
 Fail-operational — typically required to operate
not only in nominal conditions (expected), but
also in degraded situations when some parts are
not working properly (airplanes).
 Fail-safe — must safely shut down in case of single
or multiple failures (trains)
65
FACULTY OF COMPUTER
Critical Systems
◼ Safety critical
◼ deal with scenarios that may lead to loss of life, serious personal
injury, or damage to the natural environment
◼ Mission critical
◼ avoid inability to complete the overall system, project objectives
or one of the goals for which the system was designed
◼ Business critical
◼ avoid significant tangible or intangible economic costs; e.g., loss of
business or damage to reputation
◼ Security critical
◼ deal with the loss of sensitive data through theft or accidental loss
66
FACULTY OF COMPUTER
Key points
◼ To bypass the negative effects, critical systems must
be highly reliable and retain their reliability as they
evolve without incurring prohibitive costs.
◼ Software development standardization evolves in
levels, with each successive level opening the door
for new users, driving an increase in market size,
triggering new technology refinements, declining
costs and setting the stage for the next level of
standardization.
67
FACULTY OF COMPUTER
Key points
◼ Software bugs
◼ Professional and ethical responsibility in SE
◼ Code of ethics
◼ Standards
◼ Critical Systems
68

Software Quality

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Quality

Uploaded by

Copyright:

Available Formats

Faculty of Computer Science and Engineering

Infamous software bugs (1)

Infamous software bugs (2)

Mariner I software bug

AT&T’s Long-Distance Network Upgrade

◼ An estimated loss of 60 US$ million in long-

The Patriot Missile failure

The explosion of Ariane 5

Y2K bug / glitch

Professional and ethical responsibility

◼ Software engineering involves wider

Issues of professional responsibility

Issues of professional responsibility

First ethical codices

ACM/IEEE Code of Ethics

Code of ethics – preamble (1)

Code of ethics – preamble (2)

Code of ethics - principles

Code of ethics - principles

Code of ethics - principles

ACM: Code of Ethics (the preamble)

Quality criteria for software products

Curve for software reliability

Cloud application portability

◼ Industry perspective in cloud portability

Major maintainability issues

Classification of quality criteria

Importance of quality factors

Internal Quality Characteristics

External Quality Characteristics

External and internal quality

Different viewpoints of software quality

Internal and external quality criteria

internal quality criteria

Software quality assurance

OPM3® maturity model

Prince maturity model (P2MM)

Capability Maturity Model Integration

CMMI Maturity Levels

Future of CMMI V2.0

ISO 9000 family

ISO/IEC 90003: 2014

Application of ISO/IEC 90003:2014

Overview of ISO 25010

◼ Therefore, these systems are called critical systems.

You might also like