MTAT Software Engineering - PDF Free Download

MTAT.03.094 Software Engineering Lecture 14: Measurement Dietmar Pfahl Fall 2015 email: dietmar.pfahl@ut.ee

Schedule of Lectures Week 01: Introduction to SE Week 02: Requirements Engineering I Week 03: Requirements Engineering II Week 04: Analysis Week 05: Development Infrastructure I Week 06: Development Infrastructure II Week 07: Architecture and Design Week 08: No lecture Week 09: Refactoring Week 10: Verification and Validation I Week 11: Industry Lecture (Testing) Week 12: Verification and Validation II Week 13: Agile/Lean Methods Week 14: Industry Lecture (Agile) Week 15: Measurement / Course wrap-up, review and exam preparation Week 16: no lecture

Structure of Lecture 14 Measurement Measurement Basics Example Measures

Some Quotes Peter Drucker: If you can t measure it, you can t manage it. McKinsey: If you can measure it, you can manage it.

BUT Software measures can be misleading, so Either you don t use them Or you better know what they mean and how to use them.

Definitions: Measurement and Measure Scale & Unit Measurement: Measurement is the process through which values (e.g., numbers) are assigned to attributes of entities of the real world. Measure: A measure is the result of the measurement process, so it is the assignment of a value to an entity with the goal of characterizing a specified attribute. Source: Sandro Morasca, Software Measurement, in Handbook of Software Engineering and Knowledge Engineering - Volume 1: Fundamentals, pp. 239-276, Knowledge Systems Institute, Skokie, IL, USA, 2001, ISBN: 981-02- 4973-X. http://onlinestatbook.com/2/introduction/levels_of_measurement.html A Entity: Program Attribute: Size Size Measure B 4 e * 3 d * 2 c * 1 b * 0 a * LOC (lines of code)

Software Measurement Challenge Measuring physical properties (attributes): entity attribute unit* scale (type) value range* Human Height cm ratio 178 (1, 300) Human Temperature C interval 37 (30, 45) Measuring non-physical properties (attributes): entity attribute unit* scale (type) value range* Human Intelligence/IQ index ordinal 135 [0, 200] Program Modifiability???? Software properties are usually non-physical: size, complexity, functionality, reliability, maturity, portability, flexibility, understandability, maintainability, correctness, testability, coupling, coherence, interoperability, unit and range are sometimes used synonymously with scale

Measurable Entities in a SW Project An entity can represent any of the following: Process/Activity: any activity (or set of activities) related to software development and/or maintenance (e.g., requirements analysis, design, testing) these can be defined at different levels of granularity Product/Artifact: any artifact produced or changed during software development and/or maintenance (e.g., source code, software design documents) Resources: people, time, money, hardware or software needed to perform the processes Ressource role Product in Ressource tool Activity Product out

Structure of Lecture 14 Measurement Measurement Basics Example Measures

Examples of Software Product Attributes Size Length, Churn, Complexity, Functionality Modularity Cohesion Coupling Quality Value (Price)... Quality (-> ISO 9126) Functionality Reliability Usability Efficiency Maintainability Portability internal vs. external

Lines Of Code (LOC) Product Size 12 14 18????

Lines Of Code

Lines Of Code Summary Accurate, easy to measure How to interpret... Empty lines Comments Several statements on one line Language dependent Doesn't take into account complexity Useful?

McCabe's Cyclomatic Complexity Complexity of a program Number of linearly independent paths through a function Usually calculated using the control flow graph MC = e n + 2p e num of edges, n num of vertices, p num of connected components of the control flow graph MC = d + 1 d num of decision (branching) points Works only for single component analysis (not several connected components; i.e. p = 1 above)

McCabe's Cyclomatic Complexity

McCabe's Cyclomatic Complexity 2: System.out.println("----------"); for (Client c : clients) 4-5: System.out.println(c.getId() + " " + c.getfirstname()); if (clients.size() == 0) e = 7 n = 6 p = 1 MC = 3 8: System.out.println("\tNothing"); 10: System.out.println("----------");

Cyclomatic Complexity Summary Automated (available in any modern IDE) Related to testing notions MC is an upper bound for the branch coverage Each control structure was evaluated both to true and false MC is a lower bound for the path coverage All linearly independent paths were executed Related to maintainability and defects MC > 10 Probability of defects rises But to be used with care: N. Nagappan, T. Ball, A. Zeller, Mining metrics to Predict Component Failures. ICSE'2006

Exercise Calculate McCabe's cyclomatic complexity of the following code snippet: http://tinyurl.com/3gzh28j

private void drawselectclientdialog() { List<Client> allclients = domaincontroller.loadallclients(); List<String> clients = new ArrayList<String>(); for (Client client: allclients) { clients.add(client.getid() + ". " + client.getfirstname()); } String selectedclient = (String)JOptionPane.showInputDialog( this, Translations.getString("main.chooseCustomer"), Translations.getString("main.chooseCustomer"), JOptionPane.OK_CANCEL_OPTION, null, clients.toarray(), 0); Client currentclient = null; try { if (selectedclient!= null) { currentclient = domaincontroller.getclientbyid( Long.parseLong(selectedClient. split(" ")[0].replaceAll("\\.",""))); } } catch(numberformatexception e) { log.error("failed to parse client id," + " probably no client was selected"); } if (currentclient!= null) { log.info("client " + currentclient.getfirstname() + " with ID=" + currentclient.getid() + " got selected."); } else { log.info("no client selected"); } model.setcurrentclient(currentclient); } MC =???

Common OO Code Measures Measure Coupling Cohesion Cyclomatic Complexity Method Hiding Factor Attribute Hiding Factor Depth of Inheritance Tree Number of Children Weighted Methods Per Class Number of Classes Lines of Code (net and total; comment) Churn (new + changed LoC) Desirable Value Lower Higher Lower Higher Higher Low (tradeoff) Low (tradeoff) Low (tradeoff) Higher (with ident functionality) Lower (with ident functionality) Lower (with ident functionality)

Coupling & Cohesion Coupling between object classes (CBO) Number of classes referenced by a given class (FanOut) Lack of cohesion in methods (LCOM) Number of method pairs that do not share instance variables minus number of methods that share at least one instance variable By convention, LCOM := 0 if the above definition gives a negative number

Coupling Example... Traveller: CBO =?

Coupling Example... CBO = 1 (one other class referenced)

(Lack of) Cohesion Example Number of method pairs that do not share instance variables minus number of methods that share at least one instance variable LCOM = 1 2 = -1 0 0

public PersonDetails { private String _firstname; private String _surname; private String _street; private String _city; (Lack of) Cohesion Example } public PersonDetails() {} public setname(string f, String s) { _firstname = f; _surname = s; } public setaddress(string st, String c) { _street = st; _city = c; } public void printaddress() { System.out.println(_street); System.out.println(_city); } public void printname() { System.out.println(_firstname + " " + _surname); } LCOM =?

(Lack of) Cohesion Example 6 2 = 8 2 = 4 2

Simple Quality Measures (Examples) Correctness: Entity: Document (e.g. Code) Attribute: Quality (Correctness) Unit: Defect (found during QA activity) Range: [0, ) Scale type: ratio Characterisation: Direct Quantitative Objective/Subjective??? Defect Density: Entity: Document (e.g., Code) Attribute: Quality (Defect Density) Unit: Defect/LOC Range: [0, ) Scale type: ratio Characterisation: Indirect Quantitative Objective/Subjective???

Example Performance Requirements

Example Performance Requirements How to test: - Define standard work load - Expose system to standard work load for a defined period of time - Measure CPU usage Q: Should we do this for different kinds of CPUs?

Example Usability Requirements

Example Usability Requirements How to test: - Define several (typical) usage scenarios involving tasks Q and R - Select test users and classify as novice and experienced - Let 5 (or better 10, 15) novices perform the secenarios - Observe what problems they encounter - Classify and count observed problems

Examples of Software Process and Resource Attributes that can be measured Process-related: Efficiency: How fast (time, duration), how much effort (effort, cost), how much quantity/quality per time or effort unit (velocity, productivity)? Effectiveness: Do we get the results (quantity/quality) we want? e.g., test coverage Capability: CMMI level Resource-related: People: Skill, knowledge, experience, learning, motivation, personality Organisation: Maturity Method/Technique/Tool: Effectiveness, efficiency, learnability, cost

Time versus Effort Time: Entity: Some Activity (e.g., Test) Attribute: Time (or Duration) Unit: Year, Month, Week, (Work) Day, Hour, Minute, Second,... Range: [0, ) Scale type: ratio Characterisation: Direct Quantitative Objective/Subjective??? Effort: Entity: Some Activity (e.g., Test) Attribute: Effort Unit: Person-Year,, Person- Day, Person-Hour, Range: [0, ) Scale type: ratio Characterisation: Direct Quantitative Objective/Subjective???

Time versus Effort (cont d) What does it mean when I say: This task (e.g., testing) takes 4 days This task (e.g., testing) needs 4 person-days

Agile Measurement: Burn-Down & Burn-Up Both can be used to calculate (average) team velocity = Story Points (or: Storys) per Team per Sprint

What Next? For you to do: Finish and submit Lab Task 7 on time! Deadline: 1 day earlier than usually! Next week: Lab Task 7 Assessment Exam: 08-Jan-2016: 87 (of 90) seats taken 15-Jan-2016: 25 (of 90) seats taken