Software Size Estimation Approach

1
Software Size Estimation Approach

• Introduction
• Software size is the key input to most software
  cost estimating methodologies.
• We can measure size by counting number of Lines
  of Code (LOC).
• Its somewhat like measuring the human size by
  measuring height
• The height will tell whether the person will bumb
  his head when entering a door-way
• It wont tell whether the person is slim!

2
Software Size Estimation Approach

• Many software engineer argued that
• Length is misleading
• The amount of functionality of a product paints a
  better picture of product size
• There have been several metric based approaches
  for measuring functionality of software product.
• Functionality captures an intuitive notio of the
  amount of function contained in a delivered
  product.

3
Software Size Estimation Approach

• 2 Popular Metric Based approach
• Function points
• Object points
• This two approaches measure functionality of
  specification documents, but each also be applied
  to later life-cycle products

4
Software Size Estimation Approach

• Function Points Approach
• Popularized by the extensive research of A.J.
  Albrecht and J.E. Gaffney
• Related article Software Function, Source Lines
  of Code, and Development Effort Prediction A
  Software Science Validation
• Used in industry
• Considered better than LOC
• Measures Software Size from specification
• Early in the life Cycle, unlike LOC.

5
Software Size Estimation Approach

• Calculating function points
• Determine from specifications an unadjusted
  function point count UFC that involves the
  following item categories
• External Inputs
• All unique data or control inputs that cross the
  system boundary and cause processing to occur.
• Examples Input screens and tables

6
Software Size Estimation Approach

• External outputs
• All unique data or control outputs that cross the
  system boundary after processing has occurred.
• Examples Output screens and reports
• External inquiries
• All unique transactions which cross the system
  boundary to make active demands on the system.
• Examples Prompts and interrupts

7
Software Size Estimation Approach

• Internal files
• All logical groupings of data that are stored
  within a system according to some pre-defined
  conceptual schema.
• Examples Database and directories
• External interface
• All unique files or programs that cross the
  system boundary and are shared with at least one
  other system or application.
• Examples shared databases and mathematical
  routines

8
Software Size Estimation Approach

• Assign a subjective complexity rating to each
  item category on a 3-class ordinal scale
• Simple, Average or complex
• Assign a weight to each item category

9
Software Size Estimation Approach

• Unadjusted function point count (UFC) is the
  weighted sum of number of items of each category
• 15
• UFC S number of items of category i x
  Weight
• i1
• Function point count,
• FP UFC x TCF Where TCF is technical complexity
  factor

10
Software Size Estimation Approach

• Component of TCF

11
Software Size Estimation Approach

• Each component rated from 0 to 5
• 0 means irrelevant, 3 means average, 5 means
  essential
• 14
• TCF 0.65 0.01 S F i
• i1

12
Software Size Estimation Approach

• Example
• A spelling checker accepts as input a document
  file and an optional personal dictionary file.
  The user can query the number of words processed
  and the number of spelling errors found at any
  stage of processing.

13
Software Size Estimation Approach

• External inputs, A 2
• document file name, personal dictionary name
• External outputs, B 3
• misspelled word report, number-of-words processed
  message, number-of-errors-so-far message
• External enquiries, C 2
• words processed, errors so far
• External files, D 2
• document file, personal dictionary
• Internal files, E 1
• dictionary

14
Software Size Estimation Approach

• If we find that the dictionary file and the
  misspelled word report are complex and the rest
  average
• UFC 4A (52 71) 4C 10D 10E
• 42 17 42 102 101 63
• From the specification, we can consider that
  technical complexity components
• F3, F5, F9, F11, F12, F13 are 0
• F1, F2, F6, F7, F8, F14 are 3
• F4 and F10 are 5
• TCF 0.65 0.01(63 25) 0.93
• FP 630.93 59

15
Software Size Estimation Approach

• Limitation of FP
• Subjectivity in the technology factor
• Function point is suitable to measure
  functionality but not complexity aspects of
  software size
• FP is found to be effective in functionality-inten
  sive applications (e.g. data processing) and not
  so effective in algorithmically complex
  applications (e.g. compiler)

16
Software Size Estimation Approach

• Subjectivity in assigning weights
• Weights were determined subjectively from IBM
  experience
• Not necessarily applicable to other environment
• Double counting
• Internal complexity is counted in giving weights
  in UFC, and again in TCF
• Researchers have shown that TCF does not improve
  accuracy over UFC

17
Software Size Estimation Approach

• It does not measure mathematical optimization,
  various embedded systems, scientific and
  real-time process control applications as well as
  it measures information systems
• Problems with measurement theory
• Incorrectly combines measurement from different
  scales
• Weights and TCF ratings are on an ordinal scale
• Counts are on absolute scale (or at least, a
  ratio scale)
• The linear combination of the two are meaningless

18
Software Size Estimation Approach

• Object Points Approach
• With the advent of Object Oriented (OO)
  programming/development, there has been a growing
  demand for new ways to measure software size in
  an OO environment.
• According to the Cost Xpert Users manual, object
  metric based estimating is seeing an increased
  following among companies using object oriented
  techniques throughout the software life cycle.

19
Software Size Estimation Approach

• Although still relatively new, it was applied on
  a massive scale within Hewlett Packard with great
  success.
• Note that the use of the term object in Object
  Points defines screens, reports and 3GL modules
  as objects.
• This may or may not have any relationship to
  other definitions of objects, such as those
  possessing features such as class affiliation,
  inheritance, encapsulation, message passing, and
  so forth.

20
Software Size Estimation Approach

• Different counting rules for objects of that
  nature are required when used in language such as
  C
• Object Metric Approach works equally well with
  both MIS type applications and with the embedded,
  scientific, and system level programming projects
  that are not well served by function points.

21
Software Size Estimation Approach

• Its disadvantage is that it only works if the
  software development is done using object
  oriented techniques
• According to the STSC Report and Fenton, to
  compute object points an initial size measure is
  generated by counting the number of
• Screen, Reports and Third generation language
  components
• This objects are classified as simple, medium or
  difficult

22
Software Size Estimation Approach

• Complexity weight for object points

23
Software Size Estimation Approach

• Getting the object point count is very similar to
  getting the function point count described above
  adjustments are made to the raw count for
  complexity and summed to get a final count.
• The advantage of counting object points is that
  it usually takes less effort than function points
  and the results are comparable

24
Software Size Estimation Approach

• Reuse is taken into account in calculating object
  points
• Assuming that r of the objects will be reused
  from previous project, then
• New object points (Object Points) X (100-r)/100
• The new object points can be used to compute the
  estimated personmonths
• PM NOP /PROD,
• where PROD is the productivity rate

25
Software Size Estimation Approach

• New Approach
• Cost estimation remains a complex problem, which
  continues to attract considerable research
  attention.
• Researchers have attempted different approached.
• Recently, models based on artificial intelligence
  techniques have been developed.

26
Software Size Estimation Approach

• For example, Finnie and Wittig applied artificial
  neural networks (ANN) and case-based reasoning
  (CBR) to estimation of effort. Using a data set
  from Australian Software Metric Association, ANN
  was able to estimate development effort within
  25 of the actual effort in more than 75 of the
  projects, and with a MARE of less than 25!

27
Software Size Estimation Approach

• Summary
• Function points are significantly less effective
  for applications where the environmental
  interactions are secondary to the algorithmic
  requirements of the program.
• If object oriented software development is being
  used on the program, the object metric approach
  works equally well with both MIS type application
  and with the embedded, scientific, and system
  level programming projects that are not well
  served by function points.

28
Software Size Estimation Approach

• References
• 1. The Pricing Handbook, Chapter 19 Software
  Pricing, http//fast.faa.gov/pricing/c1919-4.htm
• 2. Software Size, Fenton and Pfleeger
• 3. Software Cost Estimation, Hareton Leung,
  Zhang Fan
• Department of Computing, The Hong Kong
  Polytechnic University
• 4. AI tools for software development effort
  estimation, G.R. Finnie, G.E. Wittig

29
Software Size Estimation Approach

• The End
• Prepared by,
• T.W.Koh

30
Coming Next

• Artificial Neural Networks
• On
• Software Development Effort Estimation