Scribd
Upload
29 views

Lecture - 2 - Understanding Software Quality

Uploaded by

zofashane
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
29 views

Lecture - 2 - Understanding Software Quality

Uploaded by

zofashane
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
You are on page 1/ 31

SE_340 Software Quality Engineering

Spring 2024

Course Instructor:
Ms. Seemab Khan- Lecturer (Software Engineering )
Department of Creative Technologies
Air University - Islamabad
[email protected]
About Instructor

Ms. Seemab Khan


PhD RIME (in progress)
SMME- NUST_H-12_Islamabad
MS Computer Science
HITEC University Taxila
BS Computer Science
Air University Islamabad
Lecture 2

UNDERSTANDING SOFTWARE
QUALITY
Defining Quality

Perfection
Consistency
Eliminating waste
Speed of delivery
Compliance with policies & procedures
Providing good, usable products
Doing it right the first time
Delighting or pleasing customers
Total customer service & satisfaction
Quality Types

Functional Quality — a measure of what the software


does vs. what it’s supposed to do
Non-Functional Quality – a measure of how well it
does it vs. how well it’s supposed to do it
Latent Quality — a measure of how well it will
continue to do it in the future
Quality Types

Process quality: Software processes implement best


practices of software engineering in an organizational
context. Process quality expresses the degree to which
defined processes were followed and completed.

Product quality: Software products are the output of


software processes. Product quality is determined by
the degree to which the developed software meets the
defined requirements.
Quality Types

Quality in use: Quality in use addresses the degree to


which a product is fit for purpose when exposed to a
particular context of use.
Failures Everywhere

●In April 2014, around 11 million of USA’s population was


effected by a shut down of 911 emergency services, due to a
coding error of keeping a list of max 40 million users.

●In June 2014, around 20 inmates were mistakenly released


from Texas prison due to a software glitch
Failures Everywhere
Failures Everywhere
Failures Everywhere Ariana 5
ARIANE 5- Root Cause

❑ Source: ARIANE 5 Flight 501 Failure, Report by the Inquiry Board


❑ A program segment for converting a floating point number to a signed 16 bit
integer was executed with an input data value of a 64-bit number.
❑ The segment was written for Ariane 4 and the conversion was left unprotected,
because it was thought that Ariane 4 will never attain such a value.
❑ The subsystem containing this segment was reused for Ariane 5 as it had been
successfully used over years for Ariane 4
❑ This run time error (out of range, overflow), which arose in both the active and
the backup computers at about the same time, was detected and both computers
shut themselves down.
❑ This resulted in the total loss of attitude control. This breakup was detected by
an on-board monitor which ignited the explosive charges to destroy the vehicle
in the air.
Lesson Learnt

• Adequate exception handling and redundancy strategies


(real function of a backup system, degraded modes?)
• Clear, complete, documented specifications (e.g.,
preconditions, post-conditions)
• But perhaps more importantly: usage-based testing
(based on operational profiles), in this case actual Ariane
5 trajectories
• Note this was not a complex, computing problem, but a
deficiency of the software engineering practices in place
F-18 crash & F-16 flip over

• An F-18 crashed because of a missing exception condition:


– An if ... then ... block without the else clause that was thought could not
possibly arise
• In simulation, an F-16 program bug caused the virtual plane to flip
over whenever it crossed the equator, as a result of a missing minus
sign to indicate south latitude.
– .
Fatal Therac-25 Radiation

• In 1986, a man in Texas received between 16,500-25,000


radiations in less than 10 sec, over an area of about 1 cm.
• He lost his left arm, and died of complications 5 months
later.
Errors, Faults, and Failures

• Failure: The device applied higher frequency of


radiations than what was safe. Safety range: [1...10,000
Hz]
• Fault: The software controller of the device did not have
a conditional block (if .... else statements) to perform
range checking on the frequency of the radiation to be
applied.
• Errors:
– 1. The SW developer of the device controller system
had forgotten to include a range checking conditional
block on the frequency of the radiation to be applied.
– 2. The device operator was NOT supposed to enter
anything outside [1...10,000 Hz] range.
Errors, Faults, and Failures
Software - Expectations

❑ Types of software
❑ www, embedded, desktop
❑ General Software Expectations “Good” Quality Software
❑ Quality given as answer for a number of features
❑ reliability, availability, dependability
❑ Quality needs to built into the software, assured, and verified
Software – Quality Expectations

• People:
– Consumers vs. Producers
• Quality Expectations by consumers need to be satisfied by producers
through Software Quality Assurance/ Engineering
• Producers should deliver software that: Does what is supposed to do
– Do the right things
– Does things correctly
– Do the things right
Software – Quality Expectations

• An Airline Reservation System is intended to


handle reservations and not supposed to fly planes
automatically
• Should make correct reservation
– According to specifications
Quality – Perspectives & Expectations

• Different people, different views


– Expectations based on roles and responsibilities
• Consumers
– Customers
– Users
• Producers
– Involved in management, development, maintenance, marketing, or any
other service
Quality Expectations – Consumer

• fit-for-use, doing the “right things”


• conformance, doing the “things right”
• smooth operation and interaction of software
• good enough “for the price”
Quality Expectations – Consumer

• Expectations vary for different software:


– general: functionality & reliability
– usability: GUI/end-user/web/etc.
– interoperability: embedded systems
– safety: safety-critical systems, etc.
Quality Expectations – Producer

❑ Software meeting contractual obligation


❑ Confirming to product specifications
❑ Internal characteristics that make conformance easy
❑ Design, reduced coupling
Quality Expectations – Managers

❑ “good enough" for the cost


❑ Adherence to processes and standards
❑ QA strategies that guide user’s quality requirements
Quality Expectations – General

❑ Maintenance people
❑ Usability & modularity
❑ Modifiability
❑ Deployment or packaging people
❑ Portability
❑ Marketing people
❑ Profitability & value
Reading Assignment: No Silver Bullet

● There is no “silver bullet” to these issues Inherent issues


of software
● Fundamental requirements and constraints that a software
system must satisfy (Brooks, 1987)
● Software Quality Assurance can help

● Pdf file is uploaded on GCR .You are required to read it


before the next class.
Consequences of Poor Quality

❑ Standish Group surveyed 350 companies, over 8000 projects, in


1995
❑ 31% cancelled before completed, 9-16% were delivered within
cost and budget
❑ US study (1995): 81 billion US$ spent per year for failing
software development projects
❑ http://www.it-cortex.com/Stat_Failure_Rate.htm
❑ NIST study (2002): bugs cost $ 59.5 billion a year.
❑ Earlier detection could save $22 billion.
Errors Faults and Failures
Dealing with Software Faults

You might also like