Software Quality Metrics and Economics: Exam Topics - Prof. Williams, Study notes of Software Engineering

Download Software Quality Metrics and Economics: Exam Topics - Prof. Williams and more Study notes Software Engineering in PDF only on Docsity! Agenda § Exam (thru refactoring) § Object Oriented Design Metrics § Economics of Software Quality Basic Code Metrics § Lines of Code § More lines of code = more maintenance. Of two programs of “equal functionality,” it is better to have fewer lines of code. § Philosophy: Consistent with the “refactoring” philosophy, we want code to be properly abstracted, less complex, and readable § Number of Classes § To a point, more classes are preferred over less classes. § Avoidance of “god class” or “blob class” Coupling § Measure of the interdependence among modules § Modules A and B are coupled if module A calls a routine or accesses a variable in module B. § Excessive coupling § Detrimental to modular design and prevents reuse § Larger number of couples, higher sensitivity to changes in other parts of the design è maintenance is more difficult Encapsulation § Encapsulation means that all that is seen of an object is its interface, namely the operations we can perform on the object § Attribute Hiding Factor = measure of the proportion of attributes that are “invisible” from other classes or objects § Method Hiding Factor = measure of the proportion of methods that are “invisible” from other classes or objects Inheritance § Depth of Inheritance Tree: § maximum length from the class node to the root/parent of the class hierarchy tree and is measured by the number of ancestor classes. § In cases involving multiple inheritance, the DIT is the maximum length from the node to the root of the tree § Tradeoff: § Deep trees è conceptual integrity problem (hard to understand, so more complex) L but greater reuse ☺ § Number of Children: § This metric is the number of direct descendants (subclasses) for each class. § Classes with large number of children are considered to be difficult to modify and usually require more testing because of the effects on changes on all the children. § They are also considered more complex and fault-prone because a class with numerous children may have to provide services in a larger number of contexts and therefore must be more flexible. What we need to know . . . § Identify places where the process worked and did not work § Compare actual development with defined objectives and plans § Identify problem areas and improvement needs § How does the actual development compare with what was planned? § What lessons were learned from the experience? § Should different criteria be used in the next project? § What can we improved and why? § What problems were found that need corrective action? Measurement based feedback! Quality Management Procedures are Filters! Code Review On a good day, will get 40- 50% of the defects out 200 lines of code @ 100 defects/KLOC = 20 defects 200 lines of code @ 50 defects/KLOC = 10 defects •Any process step will never get them all out. •If a process step can get half of them out . . . If you start with 20, 10 will remain. •If you start with 100, 50 will remain. •You can test (or inspect) quality in . . . You need to build it in. Review Yield § Percentage of defects in the design or code at the time of the review that were found by that review § Example: process yield Yield = 100*Defects removed before compile Defects injected before compile § Essential data: § process phase at which each defect was injected § process phase in which it was found § Phase escapes: all defects injected before or during the phase, not found before or during the phase, and found later Economics of Defect Removal (no inspections) § Experienced software engineers normally inject 100+ defects/KLOC, half are found by compiler § 50,000LOC @ 50 defects/KLOC = 2,500 defects into test § Large program: 5-10 hours defect § Around (2,500 @ 8 hours/defect) 20,000 programmer hours ==> 10 person years (trying to do this in 3 months . . . ) § 5 people could do this working days, nights, and weekends in 18 months (55.5 hours/week each) § What if they stick to their original 3 month schedule?? Redo same example § 2,500 defects § 70% average yield, find 1,750 defects § 0.5 hours per defect ==> 875 hours § now 750 defects to be found in test § 8 hours per defect ==> 6,000 hours § Total of 6,875 hours vs 20,000 hours § 8 months of testing @ 43 hours/week by 5 people § savings of 10 months!! Cost of (Poor) Quality (COQ) § Failure Costs: costs of diagnosing a failure, making necessary repairs, and getting back into operation § compile until it can compile § test until all test cases can run successfully § Appraisal Costs: the costs of evaluating the product to determine its quality level § design and code reviews § inspection times § Prevention Costs: the costs associated with identifying the causes of the defect and the actions taken to prevent them in the future § prototypes § process improvement meetings § causal analysis