1. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.1 Software Engineering: Analysis and Design - CSE3308 Software Metrics CSE3308/DMS/2004/23 Monash University - School of Computer Science and Software Engineering

2. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.2 Lecture Outline u Definitions u What should we measure? u Measuring Size vLines of Code vFunction Points u Software Cost Estimation

3. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.3 A Quote “When you can measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind: it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of a science” Lord Kelvin, 1891

4. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.4 Another Quote “Not everything that counts can be counted, and not everything that can be counted counts.” Reputed to have been on a sign hanging in Einstein’s office at Princeton

5. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.5 What is a Software Metric? u A metric is a measurement of some aspect of the software product or the software process u We take metrics for a variety of reasons vto measure the quality of a product vto assess the productivity of the people building the product vto assess the benefits (productivity and quality) of new software tools vto form a baseline so we can estimate for new tools vto help justify requests for new tools or additional training

6. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.6 The Need For Software Metrics u Software Development in general vhas excessive costs (especially in maintenance) vlow productivity vpoor quality vlack of standards u Reasons being that we fail to: vset measurable targets vmeasure the real costs in projects vquantify the quality vproperly evaluate new tools and techniques

7. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.7 Types of Metrics u Productivity Metrics vfocus on the output of the software engineering process u Quality Metrics vfocus on the conformance of the software to the implicit and explicit user requirements (fitness for use) u Technical Metrics vfocus on the character of the software, e.g. coupling and cohesion u Size-oriented Metrics vdirect measures of the output and quality of the SE process u Function-oriented Metrics vindirect measures of the output and quality of the SE process u Human-oriented Metrics vinformation about the method by which people build and use systems

8. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.8 External versus Internal Metrics u We want to be able to measure external aspects like: vMaintainability vReliability vPortability vUseability u These things are very difficult to measure directly u So we develop internal measures which are theoretically correlated with the aspect of the software which we wish to measure

9. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.9 Internal Metrics u To be a valid measure of an external aspect: vthe internal metric must be measured accurately vthere must be a relationship between what we can measure and the external behavioural attribute vthe relationship must be understood, have been validated and be expressed in terms of a formula or a model u An example vMcCabe’s cyclomatic complexity measure (measure the internal complexity of a line of code) vSaid to be related to the maintainability of a component vReasonable to assume that maintainability is related to the overall complexity of a component vBut cannot assume that cyclomatic complexity is the only measure of overall complexity or even the dominant factor in the overall complexity

10. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.10 Size-oriented metrics u Built on the past experiences of organisations u Direct measures of the software u Primary Examples vSize of a product = Kilo Lines of Code (KLOC) vProductivity = KLOC/person-month vQuality = number of faults/KLOC vCost = $/KLOC vDocumentation = pages of documentation/KLOC u Generally based on the idea of a Line of Code or Source Line of Code

11. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.11 Lines of Code u A controversial measure u Defined as one line of text in a source file u Modified by a number of factors depending upon your Source Line of Code (SLOC) Counting Standard u Simplest Standard vDon’t count blank lines vDon’t count comments vCount everything else e.g. i++; while (!the Controller.isSolved() || theController.cannotProceed()); Both lines count the same

12. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.12 A More Complex LOC Standard for C++ (see handout) u Is a logical SLOC standard as opposed to a physical SLOC standard u Divides each line up based upon the number of logical statements within each line u Tries to provide a more accurate measure of the complexity of a line u Need to do this if the assumption that the proportion of complex lines to simple lines is stable is false

13. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.13 Advantages and Disadvantages u Advantages vArtifact of software development which is easily counted vMany existing methods use LOC as a key input vA large body of literature and data based on LOC already exists u Disadvantages vProgramming language-dependent vWell-designed, but shorter, programs are penalised vDoes not easily accommodate non-procedural languages vReuse can be difficult to factor in vDifficult to develop a figure for LOC early in the development

14. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.14 Function-oriented Metrics u Concentrate on measuring the functionality of a system u Are generally independent of the programming language used u The first and by far the most popular is the FUNCTION POINT u Developed by Albrecht in 1979 for IBM u Function points are derived using vcountable measures of the software requirements domain vassessments of the software complexity

15. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.15 Calculating Function Points u Number of user inputs veach user input which provides distinct application data to the software is counted u Number of user outputs veach user output that provides application data to the user is counted, e.g. screens, reports, error messages u Number of user inquiries vAn on-line input that results in the generation of some immediate software response in the form of an output u Number of files veach logical master file, i.e. a logical grouping of data that may be part of a database or a separate file u Number of external interfaces vall machine-readable interfaces that are used to transmit information to another system are counted

16. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.16 Weighting Factor Measurement parameter Count Simple Average Complex Total Number of user Inputs x3 x4 x6 = Number of user outputs x4 x5 x7 = Number of user Inquiries x3 x4 x6 = Number of files x7 x10 x15 = Number of external interfaces x5 x7 x10 = Count total Calculating Function Points (2)

17. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.17 Calculating Function Points (3) u Once the data is collected, a complexity value is associated with each count u The organisation needs to develop criteria which determine whether a particular entry is simple, average or complex u The weighting factors should be determined empirically u Albrecht has not revealed his data for the standard weighting factors

18. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.18 Calculating Function Points (4) u We now assess the software complexity u Rate each of the factors on the next slide according to the following scale: v0- No influence v1 - Incidental v2 - Moderate v3 - Average v4 - Significant v5 - Essential

19. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.19 Complexity Questions u Does the system require reliable backup and recovery? u Are data communications required? u Are there distributed processing functions? u Is performance critical? u Will the system run in an existing, heavily utilised operational environment? u Does the system require on-line data entry? u Does the on-line data entry require the input transaction to be built over multiple screens or operations? u Are the master files updated on-line? u Are the inputs, outputs, files or inquiries complex? u Is the internal processing complex? u Is the code designed to be reusable? u Are conversion and installation included in the design? u Is the system designed for multiple installations in different organisations? u Is the application designed to facilitate change and ease of use by the user?

20. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.20 Calculating a Number Function Points (FP) = count-total x [0.65 + (0.01 x Sum(F i )] where F i are the 14 complexity adjustment values (gives ±35%)

21. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.21 Advantages and Disadvantages u Advantages vProgramming language-independent vBased on data which are known early in the project vSignificant bodies of data available u Disadvantages vdeveloped for business systems and therefore only valid for that domain (the use of Feature Points, which extend Function Points by also counting algorithms, solves this to some extent) »(see http://www.spr.com/products/feature.htm)http://www.spr.com/products/feature.htm vMany aspects are subjective and have not been validated vFunction Points have no physical meaning, it’s just a number

22. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.22 Some figures Small project: < 2000 Function Points Medium Project: 2,000 to 10,000 Function Points Large Project:: > 10,000 Function Points

23. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.23 Software Cost Estimation u Any project has the following goals with regard to costs: vto establish a budget vto have a means of controlling project costs vto monitor progress against that budget by comparing planned and estimated cost vto develop a cost database for future estimation vto ascertain costs for the planning and scheduling function u This means we need metrics which let us estimate how much a project is going to cost prior to completing the project u The sooner, the better!

24. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.24 Cost Estimation Process Size Estimation Cost Estimation software size product specs size drivers product attributes platform attributes personnel attributes project attributes development methods software costs development time phase distribution activity distribution

25. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.25 Software Cost Estimation Methods u Algorithmic - mathematical algorithms which produce a cost estimate based upon variables (e.g. COCOMO and COCOMO II) v(see http://sunset.usc.edu/research/COCOMOII/)http://sunset.usc.edu/research/COCOMOII/ u Expert Judgement - individual or group assessment of cost based upon past experience u Estimation by Analogy - comparing with completed projects u Parkinsonian - Work expands to fill the available volume u Price-to-Win - Cost estimated based upon what the customer will pay

26. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.26 Approaches to Cost Estimation u Top-down estimation vcreate an overall cost and then split the cost amongst the components vAnalogy, Parkinsonian and price-to-win are examples of top-down estimating u Bottom-up estimation vCost of each individual component is estimated by an individual (usually the person who has to build the component) vCosts for all the components are summed

27. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.27 Strengths and Weaknesses No one method is sufficient; recommend top-down expert judgement and analogy combined with bottom-up algorithmic estimation

28. CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 9B.28 References u Pressman, Roger S., Software Engineering: A Practitioner’s Approach, McGraw-Hill, 2000 (Chs. 4, 5).