Measuring software size

Transcription

1 Measuring software size

2 a question to start with have you ever written a large program? if so how did you know it was large? 2

3 outline ideas and problems associated with measuring software size assessing the size of software using KLOC function points (FPs), including the evolution of function point counting the heated debate about validity of FPs 3

4 how big is a software system and how can we measure this? who is interested in measuring the size of a software system? why is measuring software size important? how can we measure it? easy: measure the output (physical: code) tricky: measure the input (specification) 4

5 output size: counting lines of code

6 measuring software size 1000s lines of code: KLOCs internal measure of software size measures physical code size in logical units pros objective (after definition agreed) repeatable easy to count fairly easy to understand 6

7 measuring software size in KLOCs but can t measure until we ve written all the code! not commensurable across languages programming style may affect results what does it actually mean? issues in counting make comparisons difficult see Capers Jones Productivity Paradox below 7

8 how many lines?: Cobol IDENTIFICATION DIVISION PROGRAM-ID. HELLOWORLD * ENVIRONMENT DIVISION CONFIGURATION SECTION SOURCE-COMPUTER. RM-COBOL OBJECT-COMPUTER. RM-COBOL DATA DIVISION FILE SECTION PROCEDURE DIVISION MAIN-LOGIC SECTION BEGIN DISPLAY " " LINE 1 POSITION 1 ERASE EOS DISPLAY "Hello world!" LINE 15 POSITION STOP RUN MAIN-LOGIC-EXIT EXIT. 8

9 how many lines?: C #include <stdio.h> int main(void) { printf("hello World "); return 0; } 9

10 what is a line of code? should we include comments and/or white space? physical vs. logical lines of code what about styles of coding which split statements across lines? is (for a = 0; a < 5; a++) { x[a] = 0;} the same as (for a = 0; a < 5; a++) { x[a] = 0; }... 1 line or 3? (or 2?) 10

11 common definitions of KLOC K = 1000 NCLOC also known as KDSI non-comment lines only includes all partial lines used by Hewlett-Packard (F+P) can also measure CLOCs comment lines 11

12 problems with KLOCs: the Capers Jones productivity paradox T.C. Jones at IBM was among the first to recognize that measures of programming productivity in terms of lines of code are inherently paradoxical. They are paradoxical in that lines of code per unit of effort tend to emphasize longer rather than efficient or high-quality programs. Similarly, highlevel programming languages tend to be penalized when compared to assembly programs, since modern programs may utilize fewer lines of code than assembly routines to realize the same computational procedure. Walt Scacchi, Understanding Software Productivity, Advances in Software Engineering and Knowledge Engineering, D. Hurley (ed.), Volume 4, pp , (1995), citing Jones, T.C., `Measuring Programming Quality and Productivity', IBM System J. 17(1), (1978),

13 lines of code: summary 1 easy to count can do it automatically, including ignoring comments etc. cheap to compute, even for large systems comparable, but only if if same programming language used programming style used measurement rules used 13

14 lines of code: summary 2 but lacks meaning affected by programming language, coding style only available late in the process doesn t measure what the system does, only how many lines it takes to do it a measure of what the system really does would be much more useful size of system from user perspective so can we measure the size of the specification of the system? 14

15 so can we measure the size of the specification?

16 measuring specification size could just count words/lines in the text of the specification document, but same disadvantages as KLOCs rewards wordiness penalises conciseness depends on language and written style may not capture relative complexity of requirements: assumes (wrongly) that short descriptions describe simple problems short problem descriptions lead inevitably to simple solution 16

17 introducing Function Points developed by IBM in 1983 by Albrecht & Gaffney rationale: measure size of a system according to functionality delivered user rather than developer viewpoint based on specification principal version mostly relevant to data-oriented systems widely used in industry but can be complex to compute not well thought-of in some academic circles 17

18 function points: the underlying idea cost of developing a system function depends on numbers of inputs outputs file accesses interfaces to external systems complexity of function technical complexity 18

19 calculating FPs using simplified IFPUG, but others exist e.g. COSMIC 1. define scope of system 2. identify inputs, outputs, file accesses and interfaces to external systems 3. classify complexity of each function type 4. apply weightings to functions 5. calculate unadjusted FPs by summing weightings 6. derive Value Adjustment Factor for system 7. apply VAF to UFP to calculate adjusted FPs 19

20 Calculating FPs each function needs to be assessed: Total for all functions = Unadjusted FP count 20

21 UFP example: model system Example: spell checker (Fenton + Pfleeger 1997:260) User Errors found enquiry Words processed enquiry Document file Personal dictionary Spell Checker Number of words report Number of errors report Report of misspellings User Dictionary words A spell checker accepts as input a document file and an optional personal dictionary file. The checker lists all words not contained in either of these files, and reports separately the total number of words processed and the number of errors found. The user can query the number of words processed and the number of spelling errors found so far in the checking run at any stage during processing. 21

22 UFP example: calculating UFPs spell checker has 2 external inputs = 2 x 4 = 8 (document file and personal dictionary locations) 3 external outputs = 3 x 5 = 15 (misspellings, total words processed, total errors found) 2 inquiries (prompts, responses) = 2 x 4 = 8 (checks on progress for words checked, errors found) 2 external files = 2 x 10 = 20 (file to check, personal dictionary) 1 internal file = 1 x 7 = 7 (global Dictionary) assuming all components are of average complexity, UFP total (UFC) = = 58 22

23 from UFPs to Adjusted FPs need to allow for technical complexity factors compute adjustment according to particular features of system score each from 0 (irrelevant) to 5 (essential) f1 reliable back up and recovery f3 distributed function f5 heavily used configuration f7 operational ease f9 complex interface f11 re-usability f13 multiple sites F2 data communications f4 performance f6 on-line data entry f8 on-line update f10 complex processing f12 installation ease f14 facilitate change calculate Value Adjustment Factor (VAF) = (sum of complexity factors * 0.01) final count = UFP * VAF 23

24 why use function points rather than LOCs? (sales pitch: 1) advantages for developers and project managers allows you to produce project plans to quantifiable accuracy track progress manage scope creep developers can achieve assigned tasks by target date due to better estimating advantages for users based on user point of view provides for common language between technician and users calculation process helps to highlight missed requirements provide accurate estimate, allowing user better budget control. 24

25 why use function points rather than LOCs? (sales pitch: 2) why shouldn t I use lines of code? ( tend to reward inefficient design, penalise concise design no industry standards (ISO ) for lines of code cannot be used for normalizing across platform, language or by organization some 4th generation languages don t even use lines of code can be positively misleading see Capers Jones Productivity Paradox above 25

26 controversy over FPs? meanings unclear for function point computation mechanism calculation details vary IFPUG version and others differences due to choice of implementation languages! acceptability: computation is time-consuming expensive subject to variability between counters (10%) 26

27 FP developments FPs have standard conversions to KLOC for different programming languages constantly being developed, e.g. increasing precision in definitions for assessing complexity of functions version 4 includes calculations for GUIs extended to other types of applications real time object oriented simplified, more generalised version available COSMIC (ISO standard!) they continue to be controversial! 27

28 reading/sources measuring lines of code F+P: not a bad article for Wikipedia! function points Metrics and Models in Software Quality Engineering, Stephen H Kan, 2nd edition, Addison Wesley, 2003: different flavours of FPs includes useful general information on FPs 28

29 Exercises 1. Given the following development effort data, estimate the effort required to develop Module E which will be 900 KLOC long. Module KLOC Person days A B C D What factors have you not been able to take into account in your calculation? Request, retrieve, display information Receptionist Phone directory Directory data Check employee Personnel Employee data Update directory Print monthly listing Clerk Phone listing Calculate the size of the Phone Directory system in unadjusted FPs, assuming average complexity.