Block 5 Managing and Extending the OO Software

Block 5: Managing and Extending the OO Software Development Process Unit 3: Product Quality: Metrics, Verification, Validation, Testing Quality and its relationship to the products and processes of the software development process. Riyadh OU 1 6/8/2021

Section 1: Introduction to software quality What is software quality? l Early major cost component of computing systems was the development of the hardware l today, the major cost component is the development of the software. l quality only needs to be sufficiently high, l Software high quality is said to be of appropriate quality, i. e. in conformance to the requirements and expectations of the customer. l quality, in the context of software, to mean ‘of appropriate quality’. Riyadh OU 2 6/8/2021

Quality check: Is quality appropriate? • how the product operates against what was (more or less) explicitly required by the customer; • that quality and development standards have been followed, whether they be in-house rules or ISO 9000 mandated practices; • that best practice of software engineers, as professionals operating to professional standards, has been followed during development. l General types of requirements effect software quality: 1. product operation requirements, 2. product revision requirements and 3. product transition requirements. Riyadh OU 3 6/8/2021

Product operation requirements how the product will be used by the enduser. l Software quality factors (SQFs) affected by product operation requirements are: l correctness: that attribute which determines how well a system fulfils the customer’s overall objectives; reliability: that attribute which determines system can be expected to perform its intended function; efficiency: that attribute which determines the level of computing resources required perform its function; integrity: that attribute which determines how well the data is secured; usability: that attribute which determines how easy the system is to use. Riyadh OU 4 6/8/2021

Product revision requirement are requirements relating to how the product will be changed. SQFs that are affected by product revision requirements are: maintainability: that attribute which determines how easily bugs can be found and fixed; l flexibility: that attribute which determines the effort required to modify an operational system; testability: that attribute which determines how easily the system can be tested to show that 5 the customer’s requirements have been met. Riyadh OU 6/8/2021

l Product transition requirements relating to how the product will be modified for different operating environments. SQFs that are affected by product transition requirements are: portability: that attribute which determines how easily the system can be used on another machine reusability: that attribute which determines how easy it is to reuse some of the software to make future developments more cost-effective interoperability: that attribute which determines the effort required to couple one system to another. Riyadh OU 6 6/8/2021

l The popular measure for assessing correctness is defects per thousand lines of code (defects per KLOC) l defect (bugs): verified lack of conformance to requirements. l Integrity is measured by considering the proportion of ‘attacks’ on a product as opposed to bona fide uses. Riyadh OU 7 6/8/2021

Section 2: Verification, Validation and Testing Are ways of assessing the quality of a software product. l Testing is an important way in which verification, validation, and quality, can be achieved. Verification and validation l Verification is the process of checking that each system description is self-consistent, and that different system descriptions are consistent and complete with respect to each other (i. e. Are we building the product right? ). l Validation is the process of checking that each system description is consistent with the customer’s requirements (i. e. Are we building the right product? ). Riyadh OU 8 6/8/2021

Consistency and self-consistency l Two system descriptions are consistent: They do not contradict each other(they describe the same part of system l Consistency w/customer requirement Requirement is met A system description may not be self-consistent, i. e. it may not be consistent with itself. This is the situation in which one part of the system description says one thing, only to be contradicted by another part. most likely to happen in the system documentation, in which contradictory claims of the system are often made. l Completeness Everything that should have been ‘said’ in a system description has been ‘said’. more difficult task than showing consistency, l every aspect of the customer’s requirements must 9 be. Riyadh met by the system description. OU 6/8/2021

Testing is the process of executing a software system to check that it meets requirements (toolkit for validation and verification ) 4 types of testing during a software development • usability testing • developmental testing, which checks that developmental activities have been carried out correctly, and ideally is performed by development staff and checked by quality assurance (QA) staff; • requirements-based testing, which checks that a system meets the customer’s requirements, and is carried out by QA staff in conjunction with the customer; • regression testing, which occurs during developmental testing and system maintenance, and checks that fixing one bug has not introduced others. Riyadh OU 10 6/8/2021

Developmental testing • unit testing, in which units of functionality (e. g. the classes in an objectoriented system) are tested in isolation; has 5 parts: • interface testing • boundary-condition testing, • local-data testing • control-structure testing, • error-handler testing, • integration testing, in which previously unittested units are tested together; • system testing, in which the completed system is tested against the customer’s requirements. 11 Riyadh OU 6/8/2021

Section 3: Measuring software quality factors Being able to measure the software quality factors Measuring quality: obtaining values for the 11 SQFs No obvious way of evaluating a product against these factors. Software metric defined as measurable quantities can be used to infer the values for the SQFs: • accuracy: the precision with which computation and control is carried out; • auditability: ease which conformance to standards can be checked; • communication commonality: the degree to which standard interface protocols and bandwidths have been used; • completeness: the degree to which full implementation of the required functionality has been achieved; 12 • complexity: degree to which program is hard to Riyadh OU 6/8/2021 understand

• conciseness: the compactness of the program in terms of lines of code; • consistency: the use of uniform design and documentation techniques throughout the software development process; • data commonality: the use of standard classes, patterns, etc. , throughout the software development process; • execution efficiency: the run-time performance of system; • expandability: degree to which architectural, class or algorithmic design can be extended; • generality: breadth of potential application of components • hardware independence: degree to which the software is decoupled from the hardware on which it operates; • instrumentation: the degree to which the system monitors its own operation and identifies errors that do occur; • modularity: independence of classes and system components • operability: the ease of operation of the program; • robustness: damage when the program encounters an error; Riyadh OU 13 6/8/2021

l Formula used to estimate a value, Fq, for each software quality factor q: – where m 1, m 2, . . . , mn are the measured values for the metrics which relate to q , and c 1 , c 2 , . . . , cn are weightings indicating the relative importance of the metrics with respect to q. In general, different software projects will require different collections of weightings, depending on the product, the customer, etc. Riyadh OU 14 6/8/2021

l l l Lines-of-code metric A very simple measure of the complexity of a system description is given by counting the number of lines in the description. lines-of-code (LOC) metric. LOC metric provides accurate measurements of complexity. if we think that errors are introduced into a program randomly, then more lines of code means more errors. Mc. Cabe’s cyclomatic-complexity metric In 1976, measures the complexity of a method by counting the number of independent paths through a method body. HOW? By counting the number of decision points. Riyadh OU 15 6/8/2021

Riyadh OU 16 6/8/2021

Riyadh OU 17 6/8/2021

Modern object-oriented metrics l OO systems require 2 levels of complexity metric: l To measure method complexity, l To measure the complexity of the class structure. contains the following metrics: • Depth of inheritance tree (DIT): for a class, DIT is defined as its number of ancestors. higher == more difficult class • Coupling between objects (CBO): for a class, CBO is defined as # of has-a relationships with other classes. • Number of children (NOC): for a class, Number of children for class. • Response for a class (RFAC): for a class, size of the response set for the class, consists of all methods of that class + all methods of other classes called by those methods. high values = = more difficult • Lack of cohesion in methods (LCOM): for a class, Number of pairs of methods that do not make reference to the same attributes minus the # of pairs of methods that do, or zero should this be negative — in highly cohesive classes, methods will manipulate the same attributes. • Weighted methods per class (WMPC): a class, measures its complexity of behaviour. Sum of the cyclomatic complexities of each method of the class. Riyadh OU 18 6/8/2021

Section 4: Testing techniques • black-box testing we choose test cases by looking at the specification (i. e. requirements and high-level design) of the system to be tested; • white-box testing we choose test cases by looking at the detail of the implementation of the system to be tested. l Both have complementary roles in the testing process — a balanced testing strategy will contain elements of both black-box and white 19 Riyadhtesting. OU box 6/8/2021

Strategy for black-box testing l We assume that we have been given a class (package, or other subsystem) to test and that the basic operations for the class have been determined from the use cases. Test data needs to be chosen to show that the class performs those operations according to the use cases. Step 1: For each method in the class, determine the input data space(e. g. using use cases) Step 2: Partition input data space into sub-domains (using case analysis) Step 3: Test all sub-domains given by case analysis (using black-box testing for each sub-domain with extreme & middle values) Riyadh OU 20 6/8/2021

White-box testing techniques Used to concentrate on sources of developmental errors. – Logical errors on the part of the programmer are likely in code not often executed, e. g. special cases or initialization methods. Riyadh OU 21 6/8/2021

l l Two white-box testing techniques: basis-path testing: based on Tom Mc. Cabe’s cyclomatic- complexity metric. It ensures that all reachable statements in a method are tested at least once. To determine basis-path test cases: 1 - select data which will exercise the straight-through path, i. e. , loop and if conditions evaluate to false, and only default cases selected in switch statements. 2 - find data that deviates from the straight-through path at the first decision point. The process is then repeated for each subsequent decision point in the program, varying the flow in each case. l Loop testing: Loops have difficulties in testing; they can end up being executed endlessly. In Java, 3 ways in which loops can occur: simple loops, nested loops and concatenated loops. 22 Each has a different testing strategy. Riyadh OU 6/8/2021

l Problems with black-box testing • Results indicate poor coverage levels when a black -box testing strategy alone is pursued. • If a tested method’s operation depends for its behavior on the internal state of an object. l Problems with white-box testing • White-box testing alone may not reveal customer requirements that have been omitted in an implementation In general combine black-box & white-box testing. Riyadh OU 23 6/8/2021

Section 5: Formal technical reviews Inspections (or formal technical reviews) purpose is to critique a product of the software development process with a view to improving it. l The product might be a customer requirements document, a piece of code or a test or maintenance plan. l Formal, efficient, and economical method of finding errors in design and code. l Finds 60 to 100% of defects l Finds defects very early in the development process, when the cost of removal is cheap. 24 l Riyadh OU 6/8/2021

Personnel – Moderator(‘the key person in a successful inspection’): manages the inspection and provides leadership. has to organize and schedule the meetings, build infrastructure for inspection, and produce the goods with prompt reporting and followingup. Should be a programmer, but not necessarily a domain expert in the topic. – Scribe records meeting’s information about each defect found. where to find the defect, its classification, and the identity of the reviewer who found it. – Author: The developer of the product being inspected. – Reviewers: The people who do the actual inspecting(2~5). Riyadh OU 25 6/8/2021

Processes • Entry criteria for an inspection depend on the product, but in general require that the product is sufficiently mature to be used as it stands after the inspection process is complete. For software, this means that the software successfully compiles. • Exit criteria for an inspection are usually that all major defects found have been corrected. If a product satisfies the entry criteria, it can be inspected 26 The inspection process consists of seven stages Riyadh OU 6/8/2021

Planning The objectives of the planning stage are to: • determine what will be inspected; • determine whether the product is ready to be inspected; • collect supporting materials for the inspection (forms, checklists. . ) • determine reviewers; • schedule the inspection process; • help author prepare for the next stage (the overview). l l Overview Allow the inspection team to become familiar with the intention and detail of the product. Preparation for the inspection. find defects of the product and to classify their importance and type: • a major defect may cause a malfunction, or prevent the attainment of a required result; • a minor defect may cause a malfunction nor prevent the attainment of a required result l 27 Review to confirm and list major defects+responsible Riyadh OU 6/8/2021

l l l Report Within one day of the review meeting, the scribe should produce a written report of the inspection and the major defects that were found. The main objective of the report is to record who is responsible for addressing each defect. Rework The objective of reworking is to correct the defects listed in the report. Follow-up meeitng The main objective is to ensure that all major defects have been dealt with adequately. – If not, the product is failed and the reworking stage is repeated; – if they have, the product is passed, provisionally. The follow-up meeting assesses the amount of reworking that has taken place. If it is found that more than 5% of the product was reworked, the review team should reconvene and carry out a full reinspection. If less than 5% of the code had been reworked then the moderator decide with the reinspection. Once reinspection is deemed satisfactory the product is 28 Riyadh OU 6/8/2021 passed.

‘Golden rules’ for inspections 1. Inspect the product, not the producer. 2. Set an agenda and stick to it. 3. Limit debate and rebuttal. 4. Note defects +person who will be responsible for addressing it, but don’t attempt to fix them. , 5. Take written notes to record the defects. 6. Limit # of participants & insist on advance preparation 7. Develop a checklist for each product to be reviewed. 8. Allocate resources and schedule time for inspections. 9. Provide meaningful training for participants 10. Review early inspection. May not be smooth. Riyadh OU learn from inspections successes and failures. 29 6/8/2021

Summary Formal technical reviews, or inspections, are an increasingly popular technique for improving product quality. l Inspections are very widely applicable to all products of the software development process, including high-level designs and test plans, and can improve each of them. l Inspections are an important technique for the professional software engineer l Riyadh OU 30 6/8/2021