Introduction to SQA

1
CHAPTER 1

• Introduction to SQA

2
Learning Objectives

• To discuss
• Overview of Software Quality
• Definitions and Objectives of SQA
• Software quality factors

3
Overview of Software Quality

• Software is (IEEE)
• Computer program, procedures and possibly
  associated documentation and data pertaining to
  the operation of a computer system.
• Identical to ISO, list the following components
• Computer program (code)
• Procedures
• Data necessary for operating the software system.

4
Software errors, faults and failures

• Software error?
• Software faults?
• Software failures?

5
Software errors, faults and failures

• Software error coding error, logical error ?
  mistake made by people.
• Software faults result of error.
• Software failures occurs when fault execute.

6
Classification of the causes of software errors

• Faulty definition of requirement
• Client-developer communication failures
• Deliberate deviations from software requirements
• Logical design errors
• Coding errors
• Non-compliance with documentation and coding
  instructions
• Shortcomings of the testing process
• Procedure errors
• Documentation errors

7
Quality

• Popular view
• an intangible traitit can be discussed, felt,
  and judged, but cannot be weighed or measured.
• "I know it when I see it."
• quality connotes luxury, class, and taste.
• Expensive, elaborate, and more complex products
  are regarded as offering a higher level of
  quality than their humbler counterparts.
• a Cadillac is a quality car, but a Chevrolet is
  not, regardless of reliability and repair
  records or, a surround-sound hi-fi system is a
  quality system, but a single-speaker radio is
  not. According to this view, quality is
  restricted to a limited class of expensive
  products with sophisticated functionality and
  items that have a touch of class.
• ? inexpensive products can hardly be classified
  as quality products. (?)

8
Quality

• Professional view
• Crosby (1979) defines quality as "conformance to
  requirements.
• implies that requirements must be clearly stated
  such that they cannot be misunderstood.
• Then, in the development and production process,
  measurements are taken regularly to determine
  conformance to those requirements.
• The non-conformances are regarded as defectsthe
  absence of quality.

9
Quality

• Juran and Gryna (1970) define it as "fitness for
  use.
• takes customers' requirements and expectations
  into account, which involve whether the products
  or services fit their uses.
• Since different customers may use the products in
  different ways, it means that products must
  possess multiple elements of fitness for use.
• According to Juran, each of these elements is a
  quality characteristic and all of them can be
  classified into categories known as parameters
  for fitness for use.
• The two most important parameters are quality of
  design and quality of conformance.

10
Quality

• quality of conformance is concerned with
  implementation,
• quality of design measures how valid the design
  and requirements are in creating a worthwhile
  product (Pressman, 2005).

11
Software Quality IEEE Definition

• Software quality is
• 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.

12
Software Quality Pressmans Definition

• Software quality is defined as
• Conformance to explicitly stated functional and
  performance requirements, explicitly documented
  development standards, and implicit
  characteristics that are expected of all
  professionally developed software.

13
Software Quality Pressmans Definition

• 3 requirements for quality
• Specific functional requirements ? output of the
  software system
• The software quality standards mentioned in the
  contract
• Good Software Engineering Practices (GSEP), to be
  met by the developer even though not explicitly
  mentioned in the contract.

14
Definition and Objectives of SQA

• SQA (IEEE definition) is
• 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.

15
Derived from SQA definition by IEEE

• Plan and implement systematically.
• Refer to the software development process.
• Refer to the specifications of the technical
  requirements.

16
SQA Extended definition

• SQA is
• A systematic, planned set of actions necessary to
  provide adequate confidence that the software
  development process or the maintenance process 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. ? see attachment.

17
The Objectives of SQA

• Software development (process-oriented)
• Acceptable level of confidence that the software
  will conform to functional technical
  requirements.
• Acceptable level of confidence that the software
  will conform to managerial scheduling and
  budgetary requirements.
• Initiating and managing of activities for the
  improvement and greater efficiency of software
  development and SQA activities.

18
Objectives of SQA (cont..)

• Software maintenance (product-oriented)
• Acceptable level of confidence that the software
  maintenance activities will conform to the
  functional technical requirements.
• Acceptable level of confidence that the software
  maintenance activities will conform to managerial
  scheduling and budgetary requirements.
• Initiating and managing activities to improve and
  increase efficiency of software maintenance and
  SQA activities.

19
Software Quality Factors

• Content
• The need for comprehensive software quality
  requirements
• Classifications of software requirements into
  software quality factors
• The structure (categories and factors) of
  McCalls classic factor model
• The additional factors
• Those intended in defining the software quality
  requirements

20
The need for comprehension software quality
requirements

• Many cases of low customer satisfaction are
  situations where software projects have
  satisfactorily fulfilled the basic requirements
  of correctness, while suffering from poor
  performance in other important areas such as
  maintenance, reliability, software reuse, or
  training.
• One of the main causes lack of defined
  requirements pertaining to these aspects of
  software functionality.
• ? need for comprehensive definition of
  requirements that will cover all aspects of
  software use throughout all stages of the
  software life cycle.

21
The structure (categories and factors)

• McCallss factor model classifies all software
  requirements into 11 software quality factors.
• These factors are grouped into 3 categories
• Product operation factors correctness,
  reliability, efficiency, integrity, usability.
• Product revision factors maintainability,
  flexibility, testability.
• Product transition factors portability,
  reusability, interoperability.

22
Product operation software quality factors

• Correctness required accuracy, completeness of
  the output information, etc.
• Reliability determine maximum allowed software
  system failure rate.
• Efficiency resources needed to perform all the
  functions of the software in conformance to all
  requirements.
• Integrity software system security.
• Usability scope of staff resources needed to
  operate the software system.

23
Product revision software quality factors

• Maintainability determine the efforts needed to
  identify the reasons for failure, to correct it,
  and to verify the success of the corrections.
• Flexibility capabilities and efforts to support
  adaptive maintenance activities.
• Testability related to special features in the
  programs that help the testers providing
  predefined results, logfiles.

24
Product transition software quality factors

• Portability adaptation of a software system to
  other environments hardware, OS, etc.
• Reusability use other softwares module in a new
  project.
• Interoperability creating interfaces with other
  software systems or with other systems.

25
Alternative models of software quality factors

• The Evans and Marciniak factor model (Evans
  Marciniak, 1987).
• The Deutsch and Willis factor model (Deustch
  Willis, 1988).

26
Comparison

• Both exclude testability factors.
• Evan Marciniak1 12 factors, classified into 3
  categories.
• Deustch Willis2 15 factors, classified into 4
  categories.
• 5 new factors verifiability (both),
  expandability (both), safety2, manageability2,
  survivability2.

27
Additional factors

• Verifiability design and programming features
  that enable efficient verification of the design
  and programming.
• Expandability future efforts to improve service,
  or add new applications to improve usability.
• Safety eliminate condition hazardous to
  operators of equipment as a results of errors in
  process control software.
• Manageability administrative tools that support
  software modification.
• Survivability continuity of service.

28
Those interested in defining software quality
requirements

• The clients requirements document
• Assure the quality of the software product.
• The developers additional requirements document.
• Adding requirements that represent his own
  interests reusability, verifiability and
  portability.

29
Additional notes and reference

• Appendix 1
• Table 2.2 The expanded SQA definition
  comparisons with other versions (pg 27).
• Appendix 2
• Table 3.3 Factors and sub-factors (pg 49).
• Galin, D. 2004. Software Quality Assurance From
  Theory to Implementation.