0% found this document useful (0 votes)
36 views59 pages

Strategies for Engineering Quality Software

The document discusses the importance of engineering quality software, emphasizing the need for high standards to meet user expectations and reduce defects. It outlines various types of software, the implications of software defects, and strategies for ensuring quality throughout the development process. Additionally, it highlights the ethical dilemmas faced by developers in balancing quality with cost and time constraints, particularly in safety-critical systems.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
36 views59 pages

Strategies for Engineering Quality Software

The document discusses the importance of engineering quality software, emphasizing the need for high standards to meet user expectations and reduce defects. It outlines various types of software, the implications of software defects, and strategies for ensuring quality throughout the development process. Additionally, it highlights the ethical dilemmas faced by developers in balancing quality with cost and time constraints, particularly in safety-critical systems.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

PROFESSIONAL ETHICS

Engineering Quality
Software

Dr. Soad Bakry


[Link]@[Link]
Software
• Software is a set of instructions, data, or programs
that tell a computer how to perform specific tasks. It's
essentially the non-physical component of a computer
system, contrasting with the physical hardware.
• Software enables users to interact with the hardware
and achieve desired outcomes, ranging from simple
operations like opening a file to complex processes
like running simulations.
• Different types of software exist, including operating
systems, applications, and utilities, each designed for
distinct purposes.
Engineering Quality Software
Software quality is the degree to which a software
oProduct meets specified requirements and user
expectations.
o It encompasses characteristics such as perform quickly,
reliability, maintainability, and user-friendliness, going
beyond simply fulfilling functional needs.
o High-quality software ensures a positive user experience
and reduces the likelihood of errors or failures, leading to
more effective and efficient software.
The goal of software quality is to deliver a product that is
both fit for purpose and aligns with user needs.
Software Defect ( Software Bug)
o Software defects are deviations from expected behavior,
potentially impacting software value. Anything diminishing
software value for stakeholders.
o They encompass various types, including functional, logical, and
workflow bugs, spanning unit to system levels. Thus, the impact
may be trivial or very serious.
o The defect may be understated and undetectable or very obvious.
o Effective testing is crucial for identifying and mitigating these
defects, ensuring software reliability and user satisfaction.
o Addressing defects early in the development cycle is generally
more cost-effective than fixing them later.
o Understanding the types of defects helps prioritize testing efforts
and improve code quality.
Strategies for
Engineering
Quality
Software
Primary cause for poor software quality:
oMany developers do not know how to design quality into software
from the start.
oOr do not take the time to do so.

Developers must:
oDefine and follow severe engineering principles .
oLearn from past mistakes.
oUnderstand system operating environment.
oDesign systems relatively immune to human error .
Programmers make mistakes in
turning design specifications into
code
✓ About one defect for every 7-10
lines of code

Extreme pressure to reduce time to


market
✓ Resources and time to ensure
quality are often cut.
Example: Software Defects / Bugs In Windows 7
The Microsoft Windows 7 operating system contains more than
50 million lines of code. Assume that the Microsoft software
developers produced code at the accuracy rate mentioned
above ( one defect from 7-10 lines).

Even if 99.9 percent of the defects were identified


and fixed before the product was released to the
public, there would still be about one bug per
10,000 lines of code, or roughly 5,000 bugs in
Windows 7. Thus, software used daily by workers
world-wide likely contains thousands of bugs
Ethical dilemma
✓ How much additional cost and effort should be expended to ensure
products and services meet customers’ expectations?
✓Whether products could cause damage and what the legal
First release of software
✓ Usually has many defects .
✓ Organizations avoid buying the first release.
✓ Or prohibit its use in critical systems.
Established software products can also decline when
operating conditions change.
✓ Even software products that have been reliable over a long period can
falter unexpectedly when operating conditions change. )
Example: Cincinnati Bell telephone
The software in the Cincinnati Bell telephone switch had been thoroughly
tested and had operated successfully for months after it was deployed.
Later that year, however, when the time changed from daylight
saving time to standard time, the switch failed because it was
overwhelmed by the number of calls to the local “official time”
phone number from people who wanted to set their clocks.
The large increase in the number of
simultaneous calls to the same number was a
change in operating conditions that no one had
anticipated.
Software Product
Liability
Warranty Breach of warranty claim
• When the product fails to
• Assures buyers that meet the terms of its
a product meets warranty
certain standards of • Claimant must have a valid
contract that the supplier did
quality not fulfill
• Can be extremely difficult to
prove because the software
supplier writes the warranty
to limit liability
Software
Development
Methodology
• Software Development Methodology : Is a standard, proven
work process that enables systems analysts, programmers,
project managers to make controlled and orderly progress in
developing HQ SW.
• Defines activities in the software development process, and
the individual and group responsibilities for accomplishing
these activities.
• Recommends specific techniques for accomplishing the
various activities, such as using a flowchart to document the
logic of a computer program.
• Offers guidelines for managing quality of software during the
various stages of development
Software Development Process Advantage
• Easier and cheaper to avoid software problems at
the beginning than to attempt to fix damages
after the fact
• Cost to identify and remove a defect in an early
stage can be up to 100 times less than removing a
defect in distributed software
• Identify and remove errors early in the
development process is a cost-saving measure
Better To Detect Software Defects Earlier
Software
Quality
Assurance
(QA)
• Refers to methods within the development cycle
- Guarantee reliable operation of product
- Are applied at each stage in the development cycle
- Include testing before the product ships
• However, some SW manufacturing organizations consider
testing to be their only QA method!!
• Instead of checking for errors throughout the development
process, they rely primarily on testing just before the product
is delivered to the customer.
Type
of
Testing
1. Dynamic testing
[Link] behavior
➢ Check functional (operational) requirements
➢ What system does
[Link]- Operational
➢ Check non-functional attributes not covered by
functional testing
➢ Readiness of system/how well it behaves
[Link] testing
Dynamic Testing
Check the operational behavior of a SW unit by entering test data and
comparing results to the expected results.

Opacity (view of code)


Black-box testing
Tester has no knowledge of code
Often done by someone other than the coder
White-box testing
Testing all possible logic paths in the software unit, with thorough
knowledge of the logic
Dynamic Operational Testing
Unit Testing
Individual units or modules tested by developers.

Integration Testing
Occurs after successful unit testing
Software units are combined into an integrated
subsystem
Ensures that all linkages among various subsystems
System Testing
Tests the entire system as a complete entity Occurs
after successful integration testing

User Acceptance Testing


Independent testing performed by trained end users .
Ensures that the system operates as users expect.
Dynamic Non- Operational Testing
Availability testing
Examine failure events and repair times for a running
application and compare to original service level agreement

Load testing

Determine system performance (consumed


resources/response) under different loads (normal and peak
conditions)
Recovery testing
Determine how quickly system recovers after it has gone
through forced system crash or HW failure

Security testing
Check whether system is secured and protects the data

•Portability testing
Check the ease of moving a SW component from one
environment to another
Static Testing
Manual or automated review:
Code (static code reviews)
Requirements and design documents (technical reviews)
Performed before compilation
Code is not executed
Objective: prevention of errors
Walkthrough: author of work product leads a meeting to
explain the product to his team, they ask questions and make
notes
Capability Maturity
Model Integration
(CMMI)
• Defines five levels of software development maturity
• Identifies critical issues to software quality and
process improvement
• Organization conducts an assessment of its software
development practices
- Determines where they fit in the capability model
- Identifies areas for improvement
Action plans defined to upgrade the development
process
29
Safety-Critical Systems
Safety-Critical Systems
Consequences of software defects in
certain systems can be deadly Companies
must take special precautions.

Ethical decisions involve a trade-off


between quality/ease of use and cost/time
to market.
31
A system whose failure may cause injury or
death

The safe operation relies on the flawless


performance of the software

Examples
• Airplane navigation
• Roller coasters
• Elevators
• Medical devices
• Nuclear power plant reactors

32
Historical Incidents
▪ The Mariner I space probe, which was intended to make a close flyby of
the planet Venus, was ordered destroyed less than five minutes after
launch in July 1962. Faulty software code caused the flight control
computer to perform a series of unnecessary course corrections, which
threw the spacecraft dangerously off course.

▪ A Royal Air Force helicopter took off from Northern Ireland in June
1994 with 25 British intelligence officials who were heading to a
security conference in Inverness. Just 18 minutes into its flight, the
helicopter crashed on the peninsula of Kintyre in Argyll, Scotland,
killing everyone aboard. The engine management software, which
controlled the acceleration and deceleration of the engines, was
suspected of causing the crash.
Historical Incidents
▪ Between November 2000 and March 2002, therapy planning software at the National
Oncology Institute in Panama City, Panama, miscalculated the proper dosage of
radiation for patients undergoing therapy; at least eight patients died while another 20
received overdoses that caused significant health problems. Sadly, the developers of
this software had not learned from the lessons of the Therac-25 tragedy discussed in
the opening vignette.

▪ Fire broke out on a Washington, D.C., six-car Metro train as it pulled out of the
L'Enfant Plaza station in April 2007. Fire and smoke were seen under the last ear, but
thankfully, the flames did not penetrate the floor of the car. The train operator stopped
and evacuated the passengers. It was determined that the train's brake resistor grid,
which checks various subsystems and voltages, overheated and caught fire.
Monitoring software failed to perform as expected in detecting and preventing excess
power usage in equipment on the passenger rail cars, resulting in overheating and
fire.
Development of
Safety-Critical
Systems
o Safety will not automatically
result from following the
organization’s standard
development methodology
o Requires a more severe and
time-consuming development
process than other kinds of
software
o All tasks require:
• Additional steps
• More thorough
documentation
• Cautious checking and
36
rechecking
• Project safety engineer
• Explicit responsibility for the
system’s safety
• Uses a logging and monitoring
system to track hazards from the
project’s start to finish

• Hazard log
• Used at each stage of the
software development process to
assess how project team has
accounted for detected hazards

37
• Safety reviews
• Held throughout the
development process
• Safety documentation
• Including verification reviews
and signatures
• Ethical dilemmas
• Increased time and expense can
draw developers into ethical
dilemmas
• Deciding when QA staff has
performed enough testing

38
Risk Analysis:
Consider what can go wrong, the likelihood and consequences of
such occurrences, and how risks can be avoided
• Risk
• Probability of an undesirable event
occurring times the cost of the event’s
consequences
• Consequences include: Damage to
property, loss of money, injury to people
and death
For example, if an undesirable event has a 1 percent
probability of occurring and its consequences would cost
$1,000,000, then the risk can be calculated as 0.01 ×
$1,000,000, or $10,000. The risk for this event would be
considered greater than that of an event with a 10
percent probability of occurring, at a cost of $100 (0.10 x
$100 = $10). Risk
Redundancy
• Provision of multiple interchangeable components to perform a single
function.
• Used to cope with failures and errors

• During times of widespread disaster, lack of


sufficient redundant can lead to major problems.

Example: A parachute with a backup chute attached

During times of widespread disaster, lack of sufficient redundant systems can


lead to major problems. For example, the designers of the reactors at
Japan's Fukushima Daiichi Nuclear Power Plant anticipated that a strong
earthquake and even a tsunami might hit the facility. So in addition to a
main power supply, backup generators were put in place to ensure that
coolant could be circulated to the nuclear reactors even if the main power
supply was knocked out. When a 9.0 earthquake hit the area in early 2011, it
knocked out the main power supply, but the backup power supply was still
working until it was hit by a tsunami 10 meters high, twice the height of
what had been anticipated in the design of the redundant power supplies of
the plant.29
N-version programming
▪ Involves the execution of a series of
program instructions
simultaneously by two different
systems

▪ Uses different algorithms to


execute instructions that
accomplish the same result.

▪ Instructions for the two systems


can be:
✓Written by programmers from
two different companies
✓Run on different hardware
devices
➢ Results from the two systems
are compared, if a difference
is found, another algorithm is
executed to determine which
system yielded the correct
result.

Rationale
Both systems are highly unlikely
to fail at the same time under
the same conditions.
Ethical Dilemma:
Deciding what level of risk is
acceptable is difficult and
controversial decision
- If level of risk is judged to be too
great:
o Make system modifications
o Mitigate consequences of failure by
devising emergency procedures
and evacuation plans
Decide whether to make a product
recall when data indicates a problem
Reliability
is the probability of a component or system performing without failure
over its product life.
For example, if a component has a reliability of 99.9 percent,
it has one chance in one thousand of failure over its lifetime.
Although this chance of failure may seem low, remember
that most systems are made up of many components. As you
add more components, the system becomes more complex,
and the chance of failure increases. For example, assume
that you are building a complex system made up of seven
components, each with 99 percent reliability. If none of the
components has redundancy built in, the system has a 93.8
percent (.997) probability of operating successfully with no
component malfunctions over its lifetime. If you build the
same type of system using 10 components, each with 99
percent reliability, the overall probability of operating
without an individual component failure falls to 90 percent.
Thus, building redundancy into systems that are both
complex and safety critical is imperative.
Human Interface
• Must consider what human operators might do to make a system
work more safely and effectively

• Should leave the operator


little room for erroneous
judgment
• Poor design of a system
interface can greatly increase
risk.

Example: a self-medicating pain-relief


system must allow a patient to press a
button to receive more pain reliever, but
must also regulate itself to prevent an
overdose.
Quiz
CHOOSE THE BEST
ANSWER
• …. is any defect that, if not removed, could cause
a software system to fail to meet its users’ needs.

A. Software Piracy
B. Software Troubleshooting
C. Software Bug
D. Software Testing
CHOOSE THE BEST
ANSWER
• …. assures buyers that a product meets certain
standards of quality.

A. Insurance
B. Quality Management
C. Testing
D. Warranty
CHOOSE THE BEST
ANSWER
A form of software testing that involves viewing a
software unit as a device that has expected input
and output behaviours but whose internal
workings are unknown is known as:

A. White-box testing
B. Black-box testing
C. Dynamic testing
D. Static testing
CHOOSE THE BEST
ANSWER
Manual or automated review of code,
requirements and design documents is known as:

A. Static testing
B. Dynamic testing
C. White-box testing
D. Black-box testing
CHOOSE THE BEST
ANSWER
Capability Maturity Model Integration (CMMI) defines
how many software development maturity levels:

A. 4
B. 5
C. 6
D. 7
EXERCISE: TESTING TYPE
Recovery test
1. An application receives data from a network, unplug the
connecting cable. After some time, plug It back and analyze its
ability to continue receiving data.

2. Checks for functional and non-functional system behaviors.


Dynamic testing
3. Author of work product leads a meeting to explain the product
Walkthrough
to his team.
Portability test
4. Moving an application from Win 2000 to Win XP.

5. Independent testing performed by trained end users toAcceptance


ensure test
that system operates as users expect.
EXERCISE: TESTING TYPE
Security test
1. Check if anyone can login without any authorization.

2. If the number of users increased then how much CPU and memory
will be consumed, and what will be the network response time.
Load test
3. Ensures that all linkages among various subsystems work
successfully.
Integration test
4. Tester has no knowledge of code, often done by someone other
than the coder.
Black-box test
5. Individual modules tested by developers.
Unit test
EXERCISE: LABEL CASE
N-version programming
1. In order to reduce disk sector failures in data storage
devices, IBM saves a piece of data by two pieces of code
in the same application and then compares the data to
ensure that no errors occurred.

2. Drug company announces a fault in manufacture of a


Product recall
specific medicine patch and withdraws it.

3. RAID is commonly used in high-volume data Redundancy


storage for
file servers. RAID systems use many small-capacity disk
drives to store large amounts of data to provide
increased reliability. If one of the drives fail, it can be
removed and a new one inserted in its place.
EXERCISE: COMPLETE
1. Probability of a system performing without failures over its product life is called -------

2. The CMMI level where projects tailor their processes from organization standards is

called -------

3. If level of risk is judged to be too great, the software house has to ------- or -------

4. ------- involves the execution of a series of program instructions simultaneously by two

different systems.

5. A standard, proven work process that enables controlled and orderly progress in

developing HQ SW is called -------

6. Static testing is performed ------- compilation.


EXERCISE: COMPLETE
1. ------- systems require more severe and time-consuming development process than other kinds of

software.

2. Both systems are highly unlikely to fail at same time under same conditions is the rationale behind -

------

3. Ethical decisions in high quality SW development involve a trade-off between ------- and -------

4. The level of CMMI maturity that focuses on process improvement is called -------.

5. Designing ------- must consider what human operators might do to make a system work less safely

or effectively.

6. Critical systems requires --- documentation and ----- logs.


EXERCISE: TRUE/FALSE
1. The safe operation relies on flawless performance
of software. √
2. Established software products can also decline
when operating conditions change. √
3. Redundancy is the provision of multiple
interchangeable components to perform a single
function. √
4. Reliability recommends specific techniques for
accomplishing various activities, such as using a
flowchart to document logic of computer program.
5. Cost to identify and remove a defect in an early
stage can be up to 10 times less than removing a
defect in distributed software.
EXERCISE: TRUE/FALSE
1. Risk analysis is the probability of an undesirable event occurring times the magnitude

of the event’s consequences.

2. Project safety engineer has explicit responsibility for the system’s safety using a

monitoring system.

3. Organizations often buy the first product release to gain precedence in the market.

4. Objective of non-functional testing is to detect errors.

5. Testing can serve as the only QA method for SW manufacturing organizations.

6. Safety automatically results from following the organization’s standard development

methodology.
THANK YOU
Dr. Soad Bakry

[Link]@[Link]

You might also like