Lect2 quality factor

33
TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING CHAPTER 2 CHAPTER 2 Software Quality Software Quality Factors Factors Objectives: The need for comprehensive requirements documents Various types of software quality factors

Transcript of Lect2 quality factor

Page 1: Lect2 quality factor

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

Objectives:

The need for comprehensive requirements documents

Various types of software quality factors

Page 2: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

The need for comprehensive requirements documentsThe need for comprehensive requirements documents

• Cover all attributes of software and aspects of the use of software

• Help to avoid or reduce poor performance of the developed software

• To assure the full satisfaction of the users

Page 3: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Various Type of Software Quality FactorsVarious Type of Software Quality Factors

• Software quality factors are the areas which our products will show risks

• Can put into two categories: internal & external • Should focus on 3 important aspects

• Software operational characteristics• Software’s ability to undergo change• Software’s adaptability to new environment

• There are many quality factors which have been discovered• Jim McCall’s Quality Factors (1977) – 11 factors• Boehm’s Quality Factors (1978) – 7 factors• Evan’s and Marciniak Quality Factors (1987) – 12 factors• Deutsch and Willis Quality Factors (1988) – 15 factors

Page 4: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Software quality factors

Product operation factors

Product revision factors

Product transition factors

Page 5: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Page 6: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

• Correctness• Reliability• Efficiency• Integrity• Usability

Deal with requirements that directly affect the daily operation of the software

Page 7: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

• Maintainability• Flexibility• Testability

Deal with those requirements that affect a complete range of software maintenance activities

Page 8: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

• Portability• Reusability• Interoperability

Relate to the adaptation of software to other environments & its interaction with other software system

Page 9: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Correctness: the functionality matches the specification, defined in a list of the software system’s required outputs (output specification)

Output specification include:

• The output mission (e.g.: sales invoice output)

• The required accuracy of the outputs (e.g.: the probability for a non-accurate output, containing one or more mistakes, will not exceed 1%)

• The completeness of the output information (e.g.: the probability of missing data about a member will not exceed 1%)

• The up-to-datedness of the information (e.g.: the entry information of member payments and personal data are done not more than one working day)

• The availability of information (e.g.: Reaction time for queries in help desk will be less than 30 minutes on average)

• The required standards and guidelines (e.g.: user manual are comply with the client’s guidelines)

Page 10: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Reliability: deal with failures to provide service; determine the maximum allowed software system failure rate & refer to the entire system or to one or more of its separate functions.

For example:

• Heart attack detection function is required to have a failure rate of less than one per million cases

• The Bank Online System will not fail on average more than 10 minutes per month.

Page 11: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Efficiency: deal with the hardware resources needed to perform all the functions of the software system (including cpu, disk, memory, network & etc)

For example:

• A chain of stores is considering two alternative bids for a software system. Both bids consist of placing the same computers in the chain’s headquarters and its branches. The bids differ solely in the storage volume. Bid A – 20GB per branch computer & 100GB in the HQ and Bid B- 10 GB per branch & 30GB at the HQ. Bid A requires 3 communication lines but Bid B requires 2 lines. Hence Bid B is more efficient than Bid A because fewer hardware resources is required.

Page 12: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Integrity: deal with the software system security, protection from unauthorized access, to distinguish between the majority of personnel allowed to see the information and a limited group who will be allowed to add and change data.

For example:

• The Member registration system allows only the manager to access members’ information & members are allow to access their information when the username and password match with the first registered username and encrypted password

• For Bank Online System, transaction to other bank’s account can only be done when user key in a security number that will send to his/her hand phone.

Page 13: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Usability: deal with the scope of staff resources needed to train a new employee and to operate the software system

For example:

• Training a new employee will take no more than two days and at the end of the training, the employee able to handle 45 service call a day

Page 14: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Maintainability: the ability to find and fix a defect (include identify the reasons for software failures, correct the failures & to verify the success of the corrections).

Two aspects of maintainability:

• Serviceability (the probability of returning the item to normal service)

• Reparability (the probability of repairing the actual or impleading fault)

For example:

• The average time of repair for Bank Online System is 8 minutes

Some examples of maintainability requirements that related to reliability:

• The size of a software module will not exceed 30 statements

• The programming will adhere to the company coding standards & guidelines

Page 15: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Flexibility: the capabilities and efforts required to support adaptive maintenance activities (include the ability to make changes required as determined by customer)

For example:

• The teacher support software is suitable for teachers of all subjects, all school levels and non-professional able to create new types of reports according to the schoolteachers’ requirements

Page 16: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Testabiltiy: the ability to validate the system requirement

• Tesability that related to software operation: automatic diagnostics performed by the software system prior to starting the system, to find out whether all components of the software system are in working order and to obtain a report about the detected faults

For example:

• An industrial computerized control unit is programmed to calculate various measure of production status, report the performance level of the machinery, and operate a warning signal in predefined situations. A set of standard test data with known system expected correction reactions is run every morning, to check whether the computerized unit reacts properly.

Page 17: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Portability: the ability to transfer one software from one environment to another, the environment could consist of different hardware, different operating systems etc

For example:

• A software package designed and programmed to operate in a Windows 2000 environment is required to allow low-cost transfer to Linux and Windows NT environments

Page 18: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Reusability: the ease of using existing software components (software modules originally designed for one project) in a different context or a new software project.

The advantages of reusability:

• Save development resources

• Shorten development period

• Provide higher quality standards

For example:

• Software system for hotel guest and members of a pool club, the reuse module for another software system for spa might include entrance validity checks of membership cards and visit recording, restaurant billing and processing of membership renewal letters

Page 19: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Interoperability: focus on creating interfaces with other software systems or with other equipment firmware

Interoperability requirements

• can specify the names of the software or firmware for which interface is required

• can also specify the output structure accepted as standard in a specific industry or applications area.

For example:

• The firmware of a medical laboratory’s equipment is required to process its results (output) according to a standard data structure that can then serve as input for a number of standard laboratory information systems.

Page 20: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Alternative models ~ Boehm’s Quality Model

• Boehm defined three basic software requirements:– As-is utility: the extent to which the as-is

software can be used– Maintainability: ease of identifying what needs

to be changed as well as ease of modification and retesting

– Portability: ease of changing software to accommodate a new environment

Page 21: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

• The seven quality factors• Portability: the extent to which the software will work under

different computer configurations• Reliability: the extent to which the software performs as required• Efficiency: optimum use of system resources during correct

execution• Usability: ease of use• Testability: ease of validation so that the software meets

requirements• Understandability: the extent to which the software is easily

comprehended with regard to purpose & structure• Flexibility: the ease of changing the software to meet revised

requirements

Boehm’s Quality Model

Page 22: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Additional factors from Evans & Marciniak, Deutsch & Willis

• Verifiability (by E & M): define design & programming features

• Expandability (by E & M, D & W): refer to future efforts that will be needed to serve larger populations, improve service, or add new applications in order to improve usability

• Safety (by D & W): eliminate conditions hazardous to operators of equipment as a result of errors in process control software

• Manageability (by D & W): refer to the administrative tools that support software modification during the software development & maintenance periods

• Survivability (by D & W): refer to the continuity of service

Page 23: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

No. Software quality factor

McCall’s classic model

Alternative factor modelsEvans and

Marciniak modelDeutsch and Willis model

1 Correctness + + +2 Reliability + + +3 Efficiency + + +4 Integrity + + +5 Usability + + +6 Maintainability + + +7 Flexibility + + +8 Testability +9 Portability + + +10 Reusability + + +11 Interoperability + + +12 Verifiability + +13 Expandability + +14 Safety +15 Manageability +16 Survivability +

Page 24: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

What is reliability?

The probability that software will not cause a system failure for a specified time under specified conditions. The probability is a function of the inputs to, and use of, the system as well as function of the existence of faults in the software. The inputs to the system determine whether existing faults, if any, are encountered (IEEE)

Page 25: Lect2 quality factor

Characteristics of Software Reliability

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

•Cannot be defined objectively Reliability measurements which are quoted out of context are not meaningful

•Requires operational profile for its definition defines the expected pattern of software usage

•Must consider fault consequences Not all faults are equally serious. System is perceived as more unreliable if there are more serious faults

•Reliability is a dynamic system attribute

Page 26: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

The Need of Software Reliability

•Reputation - more reliable product more favorable reputation

•Customer Satisfaction - unreliable product will negatively affect customer satisfaction severely. Thus high reliability is a mandatory requirement for customer satisfaction.

•Warranty Costs - If a product fails to perform its function within the warranty period, the replacement and repair costs will negatively affect profits, as well as gain unwanted negative attention

•Repeat Business – build a good reputation among existing customers

•Cost Analysis - initial cost might be higher, but the overall lifetime cost is lower because product requires fewer repairs or less maintenance.

•Customer Requirements - customers demand a reliable system

•Competitive Advantage - gain an advantage over competitors who does not publish the reliability rate or lower failure rate

Page 27: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Errors, Failures & Faults

• ErrorsErrors are human design errors, may not be observed or are human design errors, may not be observed or detected by usersdetected by users

• A A faultfault is a static software characteristic which is a static software characteristic which causes a failure to occur. It is the expression of a software causes a failure to occur. It is the expression of a software error.error.

• A A failurefailure corresponds to unexpected run-time behavior corresponds to unexpected run-time behavior observed by a user of the softwareobserved by a user of the software

• Faults need not necessarily cause failures. They only do so Faults need not necessarily cause failures. They only do so if the if the faulty partfaulty part of the software is of the software is usedused

Page 28: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Reliability Improvement

• Reliability is improved when software faults which occur in the most frequently used parts of the software are removed

• Removing x% of software faults will not necessarily lead to an x% reliability improvement

• In a study, removing 60% of software defects actually led to a 3% reliability improvement

• Removing faults with serious consequences is the most important objective

Page 29: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Reliability & Efficiency

• As reliability increases system efficiency tends to decrease

• To make a system more reliable, redundant code must be included to carry out run-time checks, etc. This tends to slow it down

Page 30: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

• Reliability is usually more important than efficiency• No need to utilize hardware to the fullest extent as

computers are cheap and fast• Unreliable software isn't used• Hard to improve unreliable systems• Software failure costs often far exceed system

costs• Costs of data loss are very high

Reliability & Efficiency

Page 31: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

The reality

• High costs of reliability achievement• May be more cost effective to accept unreliability and

pay for failure costs• Depends on social and political factors • Depends on system type - for business systems in

particular, moderate reliability may be adequate

Page 32: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Reviews

1. Among the 16 software quality factors, which do you think is the most important one? Justify your answer(s).

Javab : reliability- tarif- 5,6 morde khososiat2. Among the 16 software quality factors, which do you think is the

least important one? Justify your answer(s).

Javab :usability we can use skillful person instead of train new employees.

Page 33: Lect2 quality factor

CHAPTER 2 CHAPTER 2 Software Quality FactorsSoftware Quality Factors

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING

Case Studies