The document discusses the process of software project management, focusing on size estimation, cost estimation, and scheduling. It includes an overview of function point analysis, detailing the methods for measuring project size based on user requirements, with functional units classified into data and transactional types. Additionally, it addresses the complexities and criticisms of function point analysis, emphasizing its independence from programming languages and the challenges in applying it consistently across different projects.

1. Activities During Software Project Management
Size Estimation
Cost Estimation Development Time
Resources
Requirements
Project
Scheduling
By. Dr. B. J. Mohite 9850098225

2. Process For Successful Projects
• Scope of work to be done
• The risk to be incurred
• The resources required
• The task to be achieved
• The cost to be expended
• The schedule to be followed.

3. Size Estimation
• IT is beginning step of estimation.
• Critical and difficult area of project planning.
• Difficult to establish units of size measuring.
• It is divided into two types like
1. LOC (Lines of Code)
2. Function Count

4. Lines Of Code
A line of code is any line of program text that
is not a comment or blank line, regardless of
the number of statements or fragments of
statements on the line. This specifically
includes all lines containing program header,
declarations, and executable and non-
executable statements.

5. Function Count
• Developed by Alan Albrecht in 1970 in IBM.
• Develop this technique is called as Function
Point Analysis.
• Used for problem size measurements.
• Function point measures functionality from
users point of view , that is , on the basis of
what the user requests and receives in return
from the system.

6. FUNCTION POINT ANALYSIS
FPA is decomposed into five functional units are
• Inputs: Information entering in the system
• Outputs: Information leaving in the system
• Enquiries: Request to access information
• Internal logical files: Information held within the system
• External interface files: Information held by other
systems that is used by the system being analyzed.

7. FPA’s fu ctio al u its
SYSTEM
OTHER
APPLICATION
USER
EIF
USER
ILFINPUTS
OUTPUTS
ENQUIRIES
FPA’s functional units

8. Two categories of functional units
1. Data Function Types:
• Internal logical files(ILF): A user identifiable group of logically
related data or control information maintained within system.
• External Interface files(EIF):A user identifiable group of
logically related data or control information referenced by
system,but maintained within another system .
(note: EIF counted for one system,ILF may be in another system)

9. Two categories of functional units
2. Transactional function Types
• External Input (EI): Process the data or control the
information that comes from the outside of the
system.
• External output (EO): Generates the data or control
information to be sent outside of the system.
• External Enquiry (EQ): Elementary process that is
made up of an input-output combination.

10. Counting function points
Functional units
Weighting factors
Low Average High
External Inputs (EI) 3 4 6
External Output (EO) 4 5 7
External Enquiries (EQ) 3 4 6
Internal Logical Files (ILF) 7 10 15
External Interface Files (EIF) 5 7 10
These function-point counts are then weighed (multiplied) by their degree of
complexity:

11. Computing function points
Rate each factor on a scale of 0 to 5
Minimum MaximumIncidental Moderate Average Significant
0 1 2 3 4 5

12. UPF calculation table
Functional
Units
Count Complexity
Complexity Totals
Functional
unit totals
External inputs
(EIs)
EI
External
outputs(Eos)
EO
External
enquiries EQs)
EQ
Internal logical
files (ILFs)
ILF
External
Interface files
(EIFs)
EIF
Total unadjusted function point count

13. EXTERNAL INPUTS
Count
Complexity
Complexity totals
FUNCTIONAL
UNIT
TOTALS
LOW * 3 =
AVERAGE * 4 =
HIGH * 6 =
Back to UPF

14. EXTERNAL OUTPUTS
Count
Complexity
Complexity totals
FUNCTIONAL
UNIT
TOTALS
LOW * 4 =
AVERAGE * 5 =
HIGH * 7 =
Back to UPF

15. EXTERNAL ENQUIRIES
Count
Complexity
Complexity totals
FUNCTIONAL
UNIT
TOTALS
LOW * 3 =
AVERAGE * 4 =
HIGH * 6 =
Back to UPF

16. INTERNAL LIGICAL FILES
Count
Complexity
Complexity totals
FUNCTIONAL
UNIT
TOTALS
LOW * 7 =
AVERAGE * 10 =
HIGH * 15 =
Back to UPF

17. EXTERNAL INTERFACE FILES
Count
Complexity
Complexity totals
FUNCTIONAL
UNIT
TOTALS
LOW * 5 =
AVERAGE * 7 =
HIGH * 10 =
Back to UPF

18. Function Point Analysis
A simple example:
inputs
3 simple X 2 = 6
4 average X 4 = 16
1 complex X 6 = 6
outputs
6 average X 5 = 30
2 complex X 7 = 14
files
5 complex X 15 = 75
inquiries
8 average X 4 = 32
interfaces
3 average X 7 = 21
4 complex X 10 = 40
Unadjusted function points 240

19. Function Point Analysis
In addition to these individually weighted function points, there are factors
that affect the project and/or system as a whole. There are a number
(~35) of these factors that affect the size of the project effort, and each is
ra ked fro 0 - o i flue ce to 5 - essential.
The following are some examples of these factors:
• Is high performance critical?
• Is the internal processing complex?
• Is the system to be used in multiple sites and/or by multiple
organizations?
• Is the code designed to be reusable?
• Is the processing to be distributed?
• and so forth . . .

20. Function Point Analysis
Continuing our example . . .
Complex internal processing = 3
Code to be reusable = 2
High performance = 4
Multiple sites = 3
Distributed processing = 5
Project adjustment factor = 17
Adjustment calculation:
Adjusted FP = Unadjusted FP X [0.65 + (adjustment factor X 0.01)]
= 240 X [0.65 + ( 17 X 0.01)]
= 240 X [0.82]
= 197 Adjusted function points

21. Function Point Analysis
But how long will the project take and how much will it
cost?
• As previously measured, programmers in our
organization average 18 function points per month.
Thus . . .
197 FP divided by 18 = 11 man-months
• If the average programmer is paid $5,200 per month
(including benefits), then the [labor] cost of the
project will be . . .
11 man-months X $5,200 = $57,200

22. Function Point Analysis
Because function point analysis is independent of
language used, development platform, etc. it can be
used to identify the productivity benefits of . . .
• One programming language over another
• One development platform over another
• One development methodology over another
• One programming department over another
• Before-and-after gains in investing in programmer
training
• And so forth . . .

23. Function Point Analysis
But there are problems and criticisms:
• Function point counts are affected by project size
• Difficult to apply to massively distributed systems or to
systems with very complex internal processing
• Difficult to define logical files from physical files
• The validity of the weights that Albrecht established – and the
consistency of their application – has been challenged
• Different companies will calculate function points slightly
different, making intercompany comparisons questionable