1. CHAPTER 1
Introduction to SQA

2. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser
Learning Objectives:
To discuss:
Overview of Software Quality
Definitions and Objectives of SQA
Software quality factors
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

4. Software errors, faults and failures
Software faults?
Software failures?
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

7. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser
Quality
Popular view:
an intangible trait—it 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. (?)
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

8. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser
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 defects—the absence of quality.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

9. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser
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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

10. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser
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).
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

12. Software Quality – Pressman’s 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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

13. Software Quality – Pressman’s 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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

17. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser
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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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 McCall’s classic factor model
The additional factors
Those intended in defining the software quality requirements
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

21. The structure (categories and factors)
McCalls’s 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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

24. Product transition software quality factors
Portability: adaptation of a software system to other environments – hardware, OS, etc.
Reusability: use other software’s module in a new project.
Interoperability: creating interfaces with other software systems or with other systems.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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).
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

26. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser
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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

27. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser
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.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

28. Those interested in defining software quality requirements
The client’s requirements document
Assure the quality of the software product.
The developer’s additional requirements document.
Adding requirements that represent his own interests: reusability, verifiability and portability.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser

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 Software Quality Assurance: From Theory to Implementation.
ESGD5125 SEM II 2009/ Dr. Samy Abu Naser