2.Software quality factors.pdf

OHT 3.1 Software Quality assurance (SQA) SWE 333 Software Quality Factors Dr. Fayez Alqahtani [email protected] Galin, SQA from theory to implementation © Pearson Education Lim...

OHT 3.1 Software Quality assurance (SQA) SWE 333 Software Quality Factors Dr. Fayez Alqahtani [email protected] Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.2 Software quality factors 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 Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.3 Stories 1 “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....” Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.4 2 “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.” Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.5 3 “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.” Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.6 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. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.7 The need for a quality requirements document A software quality is based on the quality of its requirements document (Specification). Many software applications fail because the quality of the requirements document is poor. The need for improving poor requirements documents is widespread. – Specially those requirements that receive little emphasis known as non-functional requirements (quality factors). Comprehensive definition of requirements Galin, SQA from theory to implementation © Pearson Education Limited 2004 7  OHT 3.8 So, we need what is called software quality factors to be included in the Requirements Document The different issues in software can be classified into groups called quality factors. (Sometimes non-functional requirements). There are unequal emphasis on all quality factors among SW projects as these projects vary. Scalability; maintainability; reliability… not all these quality factors will be universally “represented” in all the requirements documents (i.e. SW projects ). Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.9 Software quality models There are different software quality models: Such as Deutsch and Willis (1988), and Evans and Marciniak (1987) The classical model of software quality is: McCall quality factors model (1977) Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.10 McCall's software quality factors model Software quality factors Product operation factors Product revision factors Product transition factors Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.11 Product operation factors ❑ This category Includes all the factors that deal with requirements that directly affect the daily operation of a software. Correctness Reliability Efficiency Integrity Usability How well does it run and ease of use. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.12 Correctness: Requirements that deal with the software system’s specifications and outputs. Examples: 1. Output mission (e.g., red alarms when temperature rises above 250°F). 2. Specifying accuracies for correct outputs 🡪 affected by inaccurate data or calculations (e.g., probability of inaccurate information won’t exceed 1% ). 3. Specifying the completeness of the outputs information 🡪 affected by incomplete data (e.g., probability of missing information won’t exceed 2% ). 4. Specifying the up-to-date information (the time between the event and its consideration by the software). 5. Specifying the availability of the information (the reaction time, which is the time needed to obtain the requested information – Response time). (e.g., Reaction time for queries will be less than two seconds on average) 6. Specifying the standards for coding and documenting the software system (e.g., The software and its documentation should comply with the client’s guidelines). Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.13 Reliability: Requirements that deal with Failures to provide a service. o determine the maximum allowed software system failure rate, and can refer to the entire system or to one or more of its separate functions Example: A heart monitoring system must have a failure rate of less than one per million cases. Downtime for a system will not be more than ten minutes per month. Efficiency: Requirements that deal with the hardware resources needed to perform the functions of the software. o hardware resources : computer’s processing capabilities, data storage capability in terms of memory and disk capacity, data communication capability of the communication lines. time between recharging of the system’s portable units. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.14 Integrity: Requirements that deal with the software security. Protection of the program from unauthorized access. o (Access Control) prevent access to unauthorized persons, o (Access Audit) distinguish between the personnel allowed of “read permit”/“write permit”. Usability: Requirements that deal with the needed staff resources to train a new employee and operate the software (Software ease of use). Example: A staff member should be able to process n transactions / unit time. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.15 Product operation factors - Summary Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.16 Product revision factors ❑ Requirements that deal with Software maintenance activities (corrective / adaptive / perfective). Maintainability Flexibility Testability Can I fix it, retest, version it, and deploy it easily? Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.17 Maintainability: ○ The degree of effort needed to identify reasons (find the problem) for software failure and to correct failures and to verify the success of the corrections. o refer to the modular structure of software, the internal program documentation, and the programmer’s manual. Example: The programming will adhere to the company coding standards and guidelines. The size of a software module will not exceed 30 statements. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.18 Flexibility: Ease of making changes required in the operating environment. o changes and additions to the software in order to improve its service and to adapt it to changes in the firm’s technical or commercial environment. Testability: Ease of testing the program to ensure that it’s error-free and it meets its specifications. o E.g., 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. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.19 Product revision factors - Summary Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.20 Product transition factors ❑ Requirements that are related to the adaptation of software to other environments. Portability Reusability Interoperability Can I move the software to a different hardware? Can I reuse major portions of the code with little modification to develop new software? Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.21 Portability: Requirements that deal with the adaptation of a software system to other environments consisting of different hardware, different operating systems,..etc Reusability: Ease of re-using software modules in a different context. Interoperability: Effort required to couple a system to another system. Also, specify the output structure accepted as standard in a specific industry or applications area. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.22 Product transition factors - Summary Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.23 Quality Categories Quality Factors Broad Objectives Correctness Does it do what the customer wants? Reliability Does it do it accurately all of the time? Product operation Efficiency Does it quickly solve the problem? Integrity Is it secure? Usability Can I run it? Maintainability Can it be fixed? Product revision Flexibility Can it be changed? Testability Can it be tested? Portability Can it be used on another machine? Reusability Can part of it be reused? Product transition Interoperability Can it interface with another system? Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.24 McCalls factor model tree Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.25 Alternative factor models The two factor models from the late 1980s, alternatives to the McCall classic factor model, are: The Evans and Marciniak factor model. The Deutsch and Willis factor model. Totally five new factors were suggested. Evans and Marciniak suggest two ‘new’ ones: [offered by both models] Verifiability and Expandability. Deutsch and Willis suggest three ‘new’ ones. Safety, Manageability, and Survivability. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.26 McCall's factor model and alternative models Alternative factor models No. Software quality McCall’s classic Evans and Deutsch and factor model Marciniak model 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 + Galin, SQA from theory to implementation © Pearson Education Limited 2004  Criteria for evaluation of software OHT 3.27 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. Galin, SQA from theory to implementation © Pearson Education Limited 2004 27  OHT 3.28 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. Using Quality factors will improve requirements document by including all details and specifications Measuring those factors tell us where we need improvement. We can use quality metrics Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.29 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) Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.30 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) Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.31 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. (Correct) Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.32 So, Who Cares? Both developers and clients need to care. One group may care more than the other for certain quality factors. Certainly the nature of the app dictates more concern on some of these factors than others (safety, for example) Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 3.33 Exercise GO back to the three stories in the beginning of this presentation What software quality factors are missing ? Galin, SQA from theory to implementation © Pearson Education Limited 2004