This document discusses software engineering and software quality assurance. It begins by defining software and describing a case study on the Therac-25 radiation therapy machine which suffered from a software failure disaster. It then covers classification of causes of software errors, definitions of software quality from IEEE and Pressman, and objectives of SQA activities. Key causes of errors listed include faulty requirements, client-developer communication failures, deliberate deviations from requirements, logical design errors, coding errors, non-compliance with documentation, shortcomings in testing, procedure errors, and documentation errors. The document also discusses definitions of quality assurance and quality control and the goals of SQA in software development and maintenance.

1. Software Engineering
College of Arts, Media and Technology ,CMU.
Kittitouch S.
1.1-8-11-12

2. 

What is Software?
Software Error, Fault and Failure
 Case study:Therac-25





Classification of the causes of software errors
Software Quality
Software Quality Assurance
Quality Control
The objectives of SQA activities

3. 
Software – IEEE definition
Software is Computer programs, procedures,
and possibly associated documentation and
data pertaining to the operation of a
computer system.
Institute of Electrical and Electronics Engineers (IEEE)

4. 



Computer programs (the “code”)
Procedures
Documentation
Data necessary for operating the software
system.

5. Software failure case study

Therac-25
 The Therac-25 was a radiation therapy machine produced by Atomic
Energy of Canada Limited
 A software failure disaster.

6. 
Read the journal of Therac-25

Think about how to to prevent software
failure disaster?

Youtube Therac-25

7. 
Software error: made by programmer.

Software fault: defect in product.

Software failure: software fault is activate.

9. 1.
Faulty definition of requirements

10. 2.
Client–developer communication failures

Misunderstanding requirement, change,
design,…,etc.

11. Deliberate deviations from software
requirements
3.

The developer reuses software modules taken from an earlier
project without sufficient analysis of the changes and adaptations
needed to correctly fulfill all the new requirements.

Due to time or budget pressures, the developer decides to omit part
of the required functions in an attempt to cope with these pressures.

12. 4.
Logical design error.

13. 5.
Coding error.

14. Non-compliance with documentation and
coding instructions.
6.


Document standard.
Coding standard.

15. 7.
Shortcomings of the testing process.

Incomplete test plans leave untreated portions of the software or the
application functions and states of the system.

Failures to document and report detected errors and faults.

Failure to promptly correct detected software faults as a result of in
appropriate indications of the reasons for the fault.

Incomplete correction of detected errors due to negligence or time
pressures.

16. 8.
Procedure errors :User error

17. 9.
Documentation errors.

Omission of software functions.

Errors in the explanations and instructions given to users,
resulting in “dead ends” or incorrect applications.

Listing of non-existing software functions, that is, functions
planned in the early stages of development but later dropped,
and functions that were active in previous versions of the
software but cancelled in the current version.

18. Faulty requirements definition
Client–developer communication failures
Deliberate deviations from software
requirements
4. Logical design errors
5. Coding errors
6. Non-compliance with documentation and
coding instructions
7. Shortcomings of the testing process
8. Procedure errors
9. Documentation errors
1.
2.
3.
End of 2-1

19. 


3 students/team.
Reading George Wise story.
Discuss in team to find answer.

20. 
IEEE definition
 The degree to which a system, component, or
process meets specified requirements.
 The degree to which a system, component, or
process meets customer or user needs or
expectations.

21. 
Software quality– Pressman’s definition
 Conformance to explicitly stated functional and
performance requirements, explicitly documented
development standards, and implicit
characteristics that are expected of all
professionally developed software.

22. 1.
Specific functional requirements, which refer
mainly to the outputs of the software system.
2.
The software quality standards mentioned in
the contract.
3.
Good Software Engineering Practices (GSEP),
reflecting state-of-the-art professional
practices, to be met by the developer even
though not explicitly mentioned in the
contract.

23. 
IEEE. Definition.
 A planned and systematic pattern of all actions
necessary to provide adequate confidence that an
item or product conforms to established technical
requirements.
 A set of activities designed to evaluate the
process by which the products are developed or
manufactured. Contrast with quality control.

24. 
The IEEE SQA definition

The relevant ISO 9000-3 sections

CMM requirements.
CMM: Capability Maturity Model

25. SQA Expanded
definition
Systematic,
planned
actions are required
IEEE SQA
definition
+
Relevant Sections from
ISO9000-3
Relevant SEI-CMM
Requirement
Management
responsibilities(4.1)
Quality system (4.2)
Contract review (4.3)
-Software quality
management
-Requirement
management
-Software project
planning
-Software tracking and
oversight
More in table 2.2

26. 
Quality control is defined as
“a set of activities designed to evaluate the
quality of a developed or manufactured
product”

27. 
Software Development(process-oriented):
1.
Assuring an acceptable level of confidence that the
software will conform to functional technical
requirements.
2.
Assuring an acceptable level of confidence that the
software will conform to managerial scheduling and
budgetary requirements.
3.
Initiating and managing of activities for the
improvement and greater efficiency of software
development and SQA activities.

28. 
Software maintenance(Product-oriented):
1.
Assuring with an acceptable level of confidence that the
software maintenance activities will conform to the
functional technical requirements.
2.
Assuring with an acceptable level of confidence that the
software maintenance activities will conform to managerial
scheduling and budgetary requirements.
3.
Initiating and managing activities to improve and increase the
efficiency of software maintenance and SQA activities. This
involves improving the prospects of achieving functional and
managerial requirements while reducing costs.

29. 
The application of a systematic, disciplined,
quantifiable approach to the development,
operation and maintenance of software; that
is, the application of engineering to software.

30. 
Chapter 2:Daniel Galin. SOFTWARE QUALITY ASSURANCE From
theory to implementation. Pearson Education Limited,2004.

Therac-25:An Engineering Disaster Therac-25 Joanne Lim.,
October 1998