measuring software size - css homepageshomepages.herts.ac.uk/~comqjs1/mmse_size.pdf · 8 mmse...
Post on 10-Jul-2018
215 Views
Preview:
TRANSCRIPT
Measuring software size
27 October 2014 MMSE 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?
27 October 2014 MMSE Measuring Software Size 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
27 October 2014 MMSE Measuring Software Size 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)
output size: counting lines of code
27 October 2014 MMSE Measuring Software Size 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
27 October 2014 MMSE Measuring Software Size 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
27 October 2014 MMSE Measuring Software Size 8
how many lines?: Cobol 000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD. 000300 000400* 000500 ENVIRONMENT DIVISION. 000600 CONFIGURATION SECTION. 000700 SOURCE-COMPUTER. RM-COBOL. 000800 OBJECT-COMPUTER. RM-COBOL. 000900 001000 DATA DIVISION. 001100 FILE SECTION. 001200 100000 PROCEDURE DIVISION. 100100 100200 MAIN-LOGIC SECTION. 100300 BEGIN. 100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS. 100500 DISPLAY "Hello world!" LINE 15 POSITION 10. 100600 STOP RUN. 100700 MAIN-LOGIC-EXIT. 100800 EXIT.
27 October 2014 MMSE Measuring Software Size 9
how many lines?: C
#include <stdio.h> int main(void) { printf("Hello World”"); return 0; }
27 October 2014 MMSE Measuring Software Size 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?)
27 October 2014 MMSE Measuring Software Size 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
27 October 2014 MMSE Measuring Software Size 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, high-level 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. 37-70, (1995), citing Jones, T.C., `Measuring Programming Quality and Productivity', IBM System J. 17(1), (1978), 39-63
27 October 2014 MMSE Measuring Software Size 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
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?
27 October 2014 MMSE Measuring Software Size 14
… so can we measure the size of the specification?
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
27 October 2014 MMSE Measuring Software Size 16
27 October 2014 MMSE Measuring Software Size 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
27 October 2014 MMSE Measuring Software Size 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
27 October 2014 MMSE Measuring Software Size 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
27 October 2014 MMSE Measuring Software Size 20
Calculating FPs each function needs to be assessed:
Total for all functions = Unadjusted FP count
27 October 2014 MMSE Measuring Software Size 21
UFP example: model system
Example: spell checker (Fenton + Pfleeger 1997:260)
Spell
Checker User User Personal dictionary
Words processed enquiry Document file
Report of misspellings
Dictionary words
Number of words report Number of errors report
Errors found enquiry
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.
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) = 8 + 15 + 8 + 20 + 7 = 58
27 October 2014 MMSE Measuring Software Size 22
27 October 2014 MMSE Measuring Software Size 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)
calculate Value Adjustment Factor (VAF) = 0.65 + (sum of complexity factors * 0.01)
final count = UFP * VAF
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
27 October 2014 MMSE Measuring Software Size 24
why use function points rather than LOCs? (sales pitch: 1)
http://www.ifpug.org/about-ifpug/faqs 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.
27 October 2014 MMSE Measuring Software Size 25
why use function points rather than LOCs? (sales pitch: 2) why shouldn’t I use lines of code?
(http://www.ifpug.org/about-ifpug/faqs/) 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
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%)
27 October 2014 MMSE Measuring Software Size 26
27 October 2014 MMSE Measuring Software Size 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 October 2014 MMSE Measuring Software Size 28
reading/sources
measuring lines of code F+P: 246+ http://en.wikipedia.org/wiki/Source_lines_of_code
• not a bad article for Wikipedia! function points
Metrics and Models in Software Quality Engineering, Stephen H Kan, 2nd edition, Addison Wesley, 2003: 92-96
different flavours of FPs • http://www.ifpug.org/ • http://www.cosmicon.com/
• includes useful general information on FPs
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 1200 48 B 750 29 C 2000 86 D 1450 60 What factors have you not been able to take into account in your calculation?
2.
Phone directory
Directory data
Personnel
Employee data
Clerk
Receptionist
Phone listing
Print monthly listing Update directory
Check employee
Request, retrieve, display information
Calculate the size of the Phone Directory system in unadjusted FPs, assuming average complexity.
top related