Introductory -Chapter1 Software Quality-Chapter2

1. 14ITPK0-Software Quality
Assurance—Lecture Notes
Text Book----Daniel Galin
Mrs.C.Santhiya
Assistant Professor
TCE,Madurai
1

2. Course Outcomes
 C01-explain the Sw Quality Stds and models-Understand
 C02-Apply different project management techniques such as
configuration mgt and quality assurance practices during product
life cycle-Apply
 C03-Apply verification and validation methods such as inspection
and testing during project life cycle-Apply
 C04-Analze different software products metrics to asses the project
quality-Apply
 C05-Manage and track software prjects based on quality standards-
Apply
2

3. 3
Chapter 1
The Software Quality Challenge

4. 4
The uniqueness of software quality assurance
 DO you think that there is a bug-free software?
 Can software developers warrant their software
applications and their documentation from any bugs
or defects ?
 What are the essential elemental differences between
software and other industrial products such as
automobiles, washing machines etc?

5. 5
The essential differences between software and other
industrial products can be categorized as follows :
1. Product complexity : # of operational modes
the product permit.
2. Product visibility : SW products are
invisible.
3. Product development and production
process.

6. 6
The phases at which the possibility of detecting
defects in industrial products and software products:
SW products do not benefit from the opportunities for
detection of defects at the three phases of the production
process
Industrial products:
 Product development : QA -> product prototype
 Product production planning : Production - line
 Manufacturing : QA procedure applied
Software products:
 Product development : QA -> product prototype
 Product production planning : Not required
 Manufacturing : Copying the product & printing copies

7. 7
Factors affecting detecting defects in SW
products VS other industrial products:
Characteristic SW products Other industrial products
Complexity Usually, v. complex allowing
for v. large number of
operational options
Degree of complexity much
lower
Visibility Invisible, impossible to detect
defects or omissions by sight (
diskette or CD storing )
Visible, allowing effective
detection of defects by sight
Nature of
development and
production
process
Opportunities to detect defects
arise in only one phase,
namely product development
Opportunities to detect defects
arise in all phases of
development and production

8. 8
Important Conclusion
The great complexity as well as invisibility of
software, among other product characteristics,
make the development of SQA methodologies and
its successful implementation a highly professional
challenge

9. 9
 Pupils & students
 Hobbies
 Engineers, economics , mgt & other fields
 SW development professionals
All those SW developers are required to deal
with SW quality problems “Bugs”
The environment for which SQA
methods are developed

10. 10
SQA environment
The main characteristics of this environment :
1. Contractual conditions
2. Subjection to customer-supplier relationship
3. Required teamwork
4. Cooperation and coordination with other SW teams
5. Interfaces with other SW systems
6. The need to continue carrying out a project despite
team member changes.
7. The need to continue out SW maintenance for
extended period.

11. 11
Contractual conditions
the activities of SW development & maintenance need to
cope with :
 A defined list of functional requirements
 The project budget
 The project timetable

12. 12
Subjection to customer-supplier relationship
 SW developer must cooperate continuously
with customer :
 To consider his request to changes
 To discuss his criticisms
 To get his approval for changes

13. 13
Required teamwork
 Factors motivating the
establishment of a project team:
 Timetable requirements
 The need of variety
 The wish to benefit from professional
mutual support & review for
enhancement of project quality

14. 14
Cooperation and coordination with other
SW teams
 Cooperation may be required with:
 Other SW dev. Teams in the same org.
 HW dev. teams in the same org.
 SW & HW dev. teams of other suppliers
 Customer SW and HW dev. teams that take part
in the project’s dev.

15. 15
Interfaces with other SW Systems
 Input interfaces
 Output interfaces
 I/O interfaces to the machine’s control board,
as in medical and lab. Control systems

16. 16
The need to continue carrying out a project
despite team member changes.
 During project dev. Period we might be face :
 Leave from the members of the team
 Switch in employees
 Transfer to another city

17. 17
The need to continue out SW maintenance
for extended period.
 From 5 to 10 years , customers need continue
to utilizing their systems:
 Maintenance
 Enhancement
 Changes ( Modification )

18. 18
Chapter 2
What is Software Quality ?

19. 19
What is Software ?
 IEEE Definition:
Software Is :
Computer programs, procedures, and possibly
associated documentation and data pertaining
to the operation of a computer system.

20. 20
IEEE Definition is almost identical to
the ISO def. ( ISO/IEC 9000-3 )
 Computer programs (“Code”)
 Procedures
 Documentation
 Data necessary for operation the
SW system.

21. 21
TO sum up:
Software quality assurance always
includes :
 Code quality
 The quality of the documentation
 And the quality of the necessary SW
data

22. 22
SW errors, faults and failures
 Questions arise from HRM conference.
 An error : can be a grammatical error in one or
more of the code lines, or a logical error in
carrying out one or more of the client’s
requirements.
 Not all SW errors become SW faults.
 SW failures that disrupt our use of the software.

23. 23
The relationship between SW faults
& SW failures:
 Do all SW faults end with SW failures?
 The answer is not necessarily
 The SW fault becomes a SW failure only when it is
activated.

24. 24
Classification of the causes of SW errors
 SW errors are the cause of poor SW quality
 SW errors can be
 Code error
 Documentation error
 SW data error
 The cause of all these errors are human

25. 25
The nine causes of software errors
1. Faulty requirement definition
2. Client-developer communication failures
3. Deliberate deviation from SW 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

26. 26
Faulty requirement definition
1. Erroneous definition of requirements
2. Absence of vital requirements
3. Incomplete definition of requirements
4. Inclusion of unnecessary requirements

27. 27
Client-developer communication failures
 Misunderstandings resulting from defective
client-developer comunications.
 Misunderstanding of the client’s
requirements changes presented to the
developer
 In written forms
 Orally
 Responses to the design problems
 others

28. 28
Deliberate deviation from SW requirements
 The developer reuse SW modules taken
from the earlier project
 Due to the time budget pressure
 Due to the unapproved improvements

29. 29
Logical design errors
 This is come from systems architects,
system analysts, SW engineers such as:
 Erroneous algorithms
 Process definitions that contain sequencing
errors
 Erroneous definition of boundary conditions
 Omission of required SW system states
 Omission of definitions concerning reactions to
illegal operations

30. 30
Coding errors
 Misunderstanding the design documentation
 Linguistic errors in the prog. Lang.
 Errors in the application of CASE and other
dev. Tools
 etc

31. 31
Non-compliance with documentation and
coding
 Team members who need to coordinate
their own codes with code modules
developed by non-complying team members
 Individuals replacing the non-complying
team member will find it difficult to fully
understand his work.
 Design review to other non-complying team

32. 32
Shortcomings of the testing process
 Incomplete testing plans
 Failures to document and report errors and
faults
 Failures to promptly correct detected SW
faults as a result of inappropriate indications
of the reasons for the fault.
 Incomplete correction of detected errors.

33. 33
Procedure errors & documentation errors
 No Clarity in Hardcopy

34. 34
Software quality - Definition IEEE
1. The degree to which a system, component,
or process meets specified requirements.
2. The degree to which a system, component,
or process meets customer or user needs or
expectations.

35. 35
Software Quality Pressman’s def.
Conformance to explicitly stated functional and performance
requirements, explicitly documented standards, and implicit
characteristics that are expected of all professionally
developed software.

36. 36
Software Quality Assurance The IEEE Definition
 SQA is :
1. A planned and systematic pattern of all actions
necessary to provide adequate confidence that
an item or product conforms to established
technical requirements.
2. A set of activities designed to evaluate the
process by which the products are developed
or manufactured. Contrast with quality control.

37. 37
IEEE SQA definition – exclude the
maintenance & timetable and budget issues.
 The Author adopts the following :
 SQA should not be limited to the development process.
It should be extended to cover the long years of service
subsequent to product delivery. Adding the software
maintenance functions into the overall conception of
SQA.
 SQA actions should not be limited to technical aspects
of the functional requirements, It should include
activities that deal with scheduling and timetable and
budget .

38. 38
SQA – Expanded Definition
.
This definition corresponds strongly with the concepts at the
foundation of ISO 9000-3, 1997
and also corresponds to the main outlines of the CMM for
software
See the Table 2.2 page 27
A systematic, planned set of actions necessary to provide
adequate confidence that the software development process or
the maintenance of a software system product conforms to
established functional technical requirements as well as with the
managerial requirements of keeping the schedule and operating
within the budgetary confines.

39. 39
Software Quality Assurance Vs. Software Quality Control
 Quality Control : a set of activities designed to evaluate
the quality of a developed or manufactured product. It
take place before the product is shipped to the client.
 Quality Assurance : the main objective is to minimize
the cost of guaranteeing quality by a variety of activities
performed throughout the causes of errors, and detect and
correct them early in the dev. Process.

40. 40
The objectives of SQA activities
 Software development ( process-oriented )
 Software maintenance ( Product-oriented )

41. 41
SQA Vs Software Engineering
 SW Engineering ( IEEE def. )
1. The application of a systematic,
restricted, quantifiable approach to
the development and maintenance
of SW; that is the application of
engineering to software.