software quality assurance (sqa) swe 333
DESCRIPTION
Software Quality assurance (SQA) SWE 333. Software Quality Factors. Dr Khalid Alnafjan [email protected]. Presentation 3. Software quality factors. The need for comprehensive software quality requirements Classification of requirements into software quality factors - PowerPoint PPT PresentationTRANSCRIPT
OHT 3.1
Galin, SQA from theory to implementation © Pearson Education Limited 2004
Software Quality assurance (SQA) SWE 333
Dr Khalid [email protected]
Software Quality Factors
OHT 3.2
Galin, SQA from theory to implementation © Pearson Education Limited 2004
• The need for comprehensive software quality requirements
• Classification of requirements into software quality factors
• Product operation factors• Product revision factors• Product transition factors• Alternative models of software quality factors• Who is interested in defining quality requirements?• Software compliance with quality factors
OHT 3.3
Galin, SQA from theory to implementation © Pearson Education Limited 2004
“Our new sales information system seems okay, the invoices are correct, the inventory records are correct, the discounts granted to our clients exactly follow our very complicated discount policy, BUT our new sales information system frequently fails, usually at least twice a day, each time for twenty minutes or more. Yesterday it took an hour and half before we could get back to work . . . . Imagine how embarrassing it is to store managers . . . . Softbest, the software house that developed our computerized sales system, claims no responsibility . . . .”
OHT 3.4
Galin, SQA from theory to implementation © Pearson Education Limited 2004
“Believe it or not, our software package ‘Blackboard’ for school teachers, launched just three months ago, is already installed in 187 schools. The development team just returned from a week in Hawaii, their vacation bonus. But we have been suddenly receiving daily complaints from the ‘Blackboard’ maintenance team. They claim that the lack of failure detection features in the software, in addition to the poor programmer’s manual, have caused them to invest more than the time estimated to deal with bugs or adding minor software changes that were agreed as part of purchasing contracts with clients.”
OHT 3.5
Galin, SQA from theory to implementation © Pearson Education Limited 2004
“The new version of our loan contract software is really accurate. We have already processed 1200 customer requests, and checked each of the output contracts. There were no errors. But we did face a severe unexpected problem – training a new staff member to use this software takes about two weeks. This is a real problem in customer departments suffering from high employee turnover . . . . The project team says that as they were not required to deal with training issues in time, an additional two to three months of work will be required to solve the problem.”
OHT 3.6
Galin, SQA from theory to implementation © Pearson Education Limited 2004
There are some characteristic common to all these “but’s”:
■ All the software projects satisfactorily fulfilled the basic requirements for correct calculations
■ All the software projects suffered from poor performance in important areas such as maintenance, reliability, software reuse, or training.
■ The cause for the poor performance of the developed software projects in these areas was the lack of predefined requirements to cover these important aspects of the software’s functionality.
OHT 3.7
Galin, SQA from theory to implementation © Pearson Education Limited 2004
The need to a quality requirements document
• A software quality is based on the quality of its requirements document
• Many software applications fail because the requirements document quality is poor
• The need for improving poor requirements documents is widespread
7
OHT 3.8
Galin, SQA from theory to implementation © Pearson Education Limited 2004
We need what is called software quality factors that is included in requirements document
OHT 3.9
Galin, SQA from theory to implementation © Pearson Education Limited 2004
There are different software quality factors and models.The classic software quality factory model is McCall software quality
factor
OHT 3.10
Galin, SQA from theory to implementation © Pearson Education Limited 2004
Software quality factors
Product operation factors
Product revision factors
Product transition factors
OHT 3.11
Galin, SQA from theory to implementation © Pearson Education Limited 2004
• Correctness• Reliability• Efficiency• Integrity• Usability
OHT 3.12
Galin, SQA from theory to implementation © Pearson Education Limited 2004
Product operation factors• Correctness: extent to which a program
fulfills its specification.• Reliability: ability not to fail.• Efficiency: use of resources execution and
storage.• Integrity: protection of the program from
unauthorized access.• Usability: ease of use of the software.
12
OHT 3.13
Galin, SQA from theory to implementation © Pearson Education Limited 2004
• Maintainability• Flexibility• Testability
OHT 3.14
Galin, SQA from theory to implementation © Pearson Education Limited 2004
Product revision factors• Maintainability: effort required to locate
and fix a fault in a program.• Flexibility: ease of making changes
required by changes in operating environment.
• Testability: ease of testing the program to ensure that it is error-free and meets its specification.
14
OHT 3.15
Galin, SQA from theory to implementation © Pearson Education Limited 2004
• Portability• Reusability• Interoperability
OHT 3.16
Galin, SQA from theory to implementation © Pearson Education Limited 2004
Product transition factors• Portability: Effort required to transfer a
program from one environment to another system.
• Reusability: ease of re-using software in a different context.
• Interoperability: effort required to couple a system to another system.
16
OHT 3.17
Galin, SQA from theory to implementation © Pearson Education Limited 2004
Software quality factors
OHT 3.18
Galin, SQA from theory to implementation © Pearson Education Limited 2004
OHT 3.19
Galin, SQA from theory to implementation © Pearson Education Limited 2004
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 +
OHT 3.20
Galin, SQA from theory to implementation © Pearson Education Limited 2004
Criteria for evaluation of software quality
Examples:• Flight software that flies on a single mission
satellite will not be concerned with portability but may be very concerned with reliability.
• A software system that remains on the ground may be concerned with portability and not very concerned by reliability.
20
OHT 3.21
Galin, SQA from theory to implementation © Pearson Education Limited 2004
How Does McCall factors improve quality
• McCall quality factors could be used as a reference when preparing requirements document. Most, if not all, of those factors should be covered explicitly in the software requirements document.
• Measuring those factors tell us where we need improvement. We can use quality metrics
OHT 3.22
Galin, SQA from theory to implementation © Pearson Education Limited 2004
Software quality factors in requirements document
Correctness• Employees salaries should not be late (Wrong)• Employees salaries should be calculated accurately and must be ready
five days before the end of the month (Correct)
Reliability• The system should be working as much time as possible (Wrong)• The system should not be in failure status during working hours (9 to
4). Total time of failure status should not exceed 20 minutes per month. (Correct)
OHT 3.23
Galin, SQA from theory to implementation © Pearson Education Limited 2004
Software quality factors in requirements document
Efficiency• The GPS application should use as little as possible of mobile phone
battery (Wrong)• The GPS application should not use more than 10% of battery power
in two hours time (Correct)
Integrity• Students should be allowed to access their final marks(Wrong)• Students should be allowed to view their final marks. They should not
be able to make any changes (Correct)
OHT 3.24
Galin, SQA from theory to implementation © Pearson Education Limited 2004
Software quality factors in requirements document
Usability• The billing system should be easy to use (Wrong)• Billing staff should be able to learn the most important five functions
of the billing system in 3 working hours.
OHT 3.25
Galin, SQA from theory to implementation © Pearson Education Limited 2004
Exercise
GO back to the three stories in the beginning of this presentation
What software quality factors are missing ?
OHT 3.26
Galin, SQA from theory to implementation © Pearson Education Limited 2004
See Chapter 3 Summary and try to answer some
questions