McCa!"s Triangle of Quality

Transcription

1

2 McCa!"s Triangle of Quality Maintainability Portability Flexibility Reusability Testability Interoperability PRODUCT REVISION PRODUCT TRANSITION PRODUCT OPERATION Correctness Usability Reliability Efficiency Integrity Maintainability Internal and external attributes Number of procedure par ameters Cyclomatic complexity Reliability Portability Usability Program size in lines of code Number of error messages Length of user manual

3 Measures, Metrics and Indicators! A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process! The IEEE glossary defines a metric as a quantitative measure of the degree to which a system, component, or process possesses a given attribute.! An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, Measurement Process! Formulation. The derivation of software measures and metrics appropriate for the representation of the software that is being considered.! Collection. The mechanism used to accumulate data required to derive the formulated metrics.! Analysis. The computation of metrics and the application of mathematical tools.! Interpretation. The evaluation of metrics results in an effort to gain insight into the quality of the representation.! Feedback. Recommendations derived from the interpretation of product metrics transmitted to the software team. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

4 Goal-Oriented Software Measurement! The Goa!Question/Metric Paradigm! (1) establish an explicit measurement goal that is specific to the process activity or product characteristic that is to be assessed! (2) define a set of questions that must be answered in order to achieve the goal, and! (3) identify well-formulated metrics that help to answer these questions.! Goal definition template! Analyze {the name of activity or attribute to be measured}! for the purpose of {the overall objective of the analysis}! with respect to {the aspect of the activity or attribute that is considered}! from the viewpoint of {the people who have an interest in the measurement}! in the context of {the environment in which the measurement takes place}. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, Metrics Attributes! simple and computable. It should be relatively easy to learn how to derive the metric, and its computation should not demand inordinate effort or time! empirically and intuitively persuasive. The metric should satisfy the engineer s intuitive notions about the product attribute under consideration! consistent and objective. The metric should always yield results that are unambiguous.! consistent in its use of units and dimensions. The mathematical computation of the metric should use measures that do not lead to bizarre combinations of units.! programming language independent. Metrics should be based on the analysis model, the design model, or the structure of the program itself.! an effective mechanism for quality feedback. That is, the metric should provide a software engineer with information that can lead to a higher quality end product These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

5 Collection and Analysis Principles! Whenever possible, data collection and analysis should be automated;! Valid statistical techniques should be applied to establish relationship between internal product attributes and external quality characteristics! Interpretative guidelines and recommendations should be established for each metric These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, Analysis Metrics! Function-based metrics: use the function point as a normalizing factor or as a measure of the size of the specification! Specification metrics: used as an indication of quality by measuring number of requirements by type These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

6 Function-Based Metrics! The function point metric (FP), first proposed by Albrecht [ALB79], can be used effectively as a means for measuring the functionality delivered by a system.! Function points are derived using an empirical relationship based on countable (direct) measures of software s information domain and assessments of software complexity! Information domain values are defined in the following manner:! number of external inputs (EIs)! number of external outputs (EOs)! number of external inquiries (EQs)! number of internal logical files (ILFs)! Number of external interface files (EIFs) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, Function Points Information Weighting factor Domain Value Count simple average complex External Inputs (EIs) = External Outputs (EOs) = External Inquiries (EQs) = Internal Logical Files (ILFs) = External Interface Files (EIFs) = Count total These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

7 What it Refactoring? Refactoring is a disciplined process of changing a software system in such a way that it does not alter the external behavior of the code while at the same time improves its internal structure. 14

8 Refactoring Martin Fowler (and Kent Beck, John Brant, William Opdyke, Don Roberts), Refactoring- Improving the Design of Existing Code, Addison Wesley, Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. Refactor (verb): to restructure software by applying a series of refactorings. 15 Why should refactoring be done? Argument 1 Refactoring Improves the Design of Software. - Without refactoring, the design of the program will decay. As people change code - changes to realize short-term goals or changes made without a full comprehension of the design of the code - the code loses its structure. 16

9 When should refactoring be done? Argument 2 Refactoring makes software easier to understand. - There are users of your code. The computer, the writer, and the updater. The most important is the updater. Who cares if the compiler takes a few more cycles to compile your code. If it takes someone 3 weeks to update your code that is a problem. 17 Who should be doing refactoring? Argument 3 Refactoring helps you find bugs. - Part of refactoring code is understanding the code and putting that understanding back into the code. In that process a clarification takes place. In that clarification bugs will be found. 18

10 Who should be doing refactoring? Argument 4 Refactoring Helps you Program Faster. - Without a good design, you can progress quickly for a while, but soon poor design start to slow you down. You spend time finding and fixing bugs and understanding the system instead of adding new function. New features need more coding as you patch over patches.. 19 Bad smells.! Knowing how to refactor something does not tell you when to refactor and how much to refactor.! Kent Beck and Martin Fowler coined a phrase Bad Smells to describe the hint of when to refactor.! This phrase was meant to reflect the ability and experience gained over time by a programmer that is needed to recognize bad coding structure. 20

11 Bad Smell Examples! Duplicate Code! Long Methods! Large Classes! Long Parameter Lists! Feature Envy! Data Clumps! Primitive Obsession 21 Bad smells in code! Duplicated code! The #1 bad smell! Same expression in two methods in the same class?! Make it a private ancillary routine and parameterize it - gather duplicated code! (Extract method)! Same code in two related classes?! Push commonalities into closest mutual ancestor and parameterize! Use template method DP for variation in subtasks - gather similar parts, leaving holes! (Form template method) 22

12 Bad smells in code Duplicated code Same code in two unrelated classes? Ought they be related? Introduce abstract parent (Extract class, Pull up method) Does the code really belongs to just one class? Make the other class into a client (Extract method) 23! Long method Bad smells in code! Often a sign of:! Trying to do too many things! Poorly thought out abstractions and boundaries! Best to think carefully about the major tasks and how they inter-relate.! Break up into smaller private methods within the class! (Extract method)! Delegate subtasks to subobjects that know best (i.e., template method DP)! (Extract class/method, Replace data value with object) 24

13 Bad smells in code Long method - Fowler s heuristic: When you see a comment, make a method. Often, a comment indicates: The next major step Something non-obvious whose details detract from the clarity of the routine as a whole. In either case, this is a good spot to break it up. 25 Bad smells in code! Feature envy! A method seems more interested in another class than the one it s defined in! e.g., a method A::m() calls lots of get/set methods of class B! Solution:! Move m() (or part of it) into B! (Move method/field, extract method)! Exceptions:! Visitor/iterator/strategy DP where the whole point is to decouple the data from the algorithm! Feature envy is more of an issue when both A and B have interesting data 26

14 Why not refactor? Conventional wisdom would discourage modifying a design You might break something in the code You have to update the documentation Both expensive But, there are longer term concerns: sticking with an inappropriate design Makes the code harder to change Makes the code harder to understand and maintain Very expensive in the long run 27 Refactoring Philosophy Make all changes small and methodical Follow design patterns Retest the system after each change By rerunning all of your unit tests If something breaks, it s easy to see what caused the failure 28

15 Principles of Refactoring In general, each refactoring aims to decompose large objects into smaller ones distribute responsibility Like design patterns Adds composition and delegation In some sense, refactorings are ways of applying design patterns to existing code 29 Obstacles to Refactoring Complexity Changing design is hard, understanding code is hard Possibility to introduce errors Mitigated by testing Clean first Then add new functionality Cultural Issues Producing negative lines of code, what an idea! We pay you to add new features, not to improve the code! If it ain t broke, don t fix it We do not have a problem, this is our software! 30

16 RefactorIT - Rename Renames a method, field, type, package or prefix. Updates all references.! Move Class Moves a class or interface into another package.! Encapsulate Field Replaces direct field usage with corresponding accessor methods.! Extract Method Analyzes the selected piece of code and extracts it into a separate method.! Extract Superclass/Interface Extracts selected methods and fields into new superclass or interface. 31