Software Project Planning

After the finalization of SRS, we would like to

estimate size, cost and development time of the
project. Also, in many cases, customer may like to
know the cost and development time even prior to
finalization of the SRS.

1
 Software Project Planning

In order to conduct a successful software project, we

must understand:
 Scope of work to be done
 The risk to be incurred
 The resources required
 The task to be accomplished
 The cost to be expended
 The schedule to be followed
2
 Project Planning
• Estimation
– Cost
– Duration
– Effort
• Scheduling
• Staffing
• Risk Management
• Miscellaneous plans

3
 The SPMP document
• Introduction
– Objectives
– Major functions
– Performance Issues
– Management and technical constraints
• Project estimates
– Effort , resources, cost, duration etc
• Scheduling
• Staffing
• Risk Management
• Project tracking and control plan
• Miscellaneous plans

4
 Software Project Planning
Software planning begins before technical work starts, continues as
the software evolves from concept to reality, and culminates only
when the software is retired.
Size estimation

Cost estimation Development time

Resources
requirements

Fig. 1: Activities during Software

Project
Project Planning scheduling
5
 Software Project Planning
Size Estimation Fig. 2: Function for sorting an array
1. int. sort (int x[ ], int n)
Lines of Code (LOC) 2. {

3. int i, j, save, im1;

If LOC is simply a count of 4. /*This function sorts array x in ascending order */
5. If (n<2) return 1;
the number of lines then 6. for (i=2; i<=n; i++)
figure shown below contains 7. {
8. im1=i-1;
18 LOC . 9. for (j=1; j<=im; j++)
10. if (x[i] < x[j])

When comments and blank 11.

12.
{
Save = x[i];
lines are ignored, the 13. x[i] = x[j];
program in figure 2 shown 14.
15.
x[j] = save;
}
below contains 17 LOC. 16. }
17. return 0;
18. }

6
 Software Project Planning
Furthermore, if the main interest is the size of the program
for specific functionality, it may be reasonable to include
executable statements. The only executable statements in
figure shown above are in lines 5-17 leading to a count of
13. The differences in the counts are 18 to 17 to 13. One
can easily see the potential for major discrepancies for
large programs with many comments or programs written
in language that allow a large number of descriptive but
non-executable statement. Conte has defined lines of code
as:

7
 Software Project Planning

“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,
declaration, and executable and non-executable
statements”.

This is the predominant definition for lines of code used

by researchers. By this definition, figure shown above
has 17 LOC.

8
 Software Project Planning
Function Count
Alan Albrecht while working for IBM, recognized the
problem in size measurement in the 1970s, and
developed a technique (which he called Function Point
Analysis), which appeared to be a solution to the size
measurement problem.

9
 Software Project Planning
The principle of Albrecht’s function point analysis (FPA)
is that a system is decomposed into functional units.

 Inputs : information entering the system

 Outputs : information leaving the system
 Enquiries : requests for instant access to
information
 Internal logical files : information held within the
system
 External interface files : information held by other system
that is used by the system being
analyzed.

10
 Software Project Planning
The FPA functional units are shown in figure given below:

User

Inquiries

Other
ILF
applications
Inputs
EIF
User
Outputs ILF: Internal logical files
System EIF: External interfaces

Fig. 3: FPAs functional units System 11

 Software Project Planning

The five functional units are divided in two categories:

(i) Data function types

 Internal Logical Files (ILF): A user identifiable group of

logical related data or control information maintained
within the system.
 External Interface files (EIF): A user identifiable group of
logically related data or control information referenced by
the system, but maintained within another system. This
means that EIF counted for one system, may be an ILF in
another system.
12
 Software Project Planning
(ii) Transactional function types
 External Input (EI): An EI processes data or control information
that comes from outside the system. The EI is an elementary
process, which is the smallest unit of activity that is meaningful
to the end user in the business.
 External Output (EO): An EO is an elementary process that
generate data or control information to be sent outside the
system.
 External Inquiry (EQ): An EQ is an elementary process that is
made up to an input-output combination that results in data
retrieval.

13
 Software Project Planning
Special features

 Function point approach is independent of the language,

tools, or methodologies used for implementation; i.e. they
do not take into consideration programming languages,
data base management systems, processing hardware or
any other data base technology.
 Function points can be estimated from requirement
specification or design specification, thus making it
possible to estimate development efforts in early phases of
development.

14
 Software Project Planning

 Function points are directly linked to the statement of

requirements; any change of requirements can easily
be followed by a re-estimate.
 Function points are based on the system user’s
external view of the system, non-technical users of
the software system have a better understanding of
what function points are measuring.

15
 Software Project Planning

Counting function points

Weighting factors
Functional Units
Low Average High
External Inputs (EI) 3 4 6
External Output (EO) 4 5 7
External Inquiries (EQ) 3 4 6
Internal logical files (ILF) 7 10 15
External Interface files 5 7 10
(EIF)
Table 1 : Functional units with weighting factors
16
 Software Project Planning
Table 2: UFP calculation table
Functional Count Complexity Functional
Units Complexity Totals Unit Totals
External Low x 3 =
Inputs Average x 4 =
(EIs) High x 6 =
External Low x 4 =
Outputs Average x 5 =
(EOs) High x 7 =
External Low x 3 =
Inquiries Average x 4 =
(EQs) High x 6 =
External Low x 7 =
logical Average x 10 =
Files (ILFs) High x 15 =
External Low x 5 =
Interface Average x 7 =
Files (EIFs) High x 10 =

Total Unadjusted Function Point Count

17
 Software Project Planning

The weighting factors are identified for all

functional units and multiplied with the functional
units accordingly. The procedure for the
calculation of Unadjusted Function Point (UFP) is
given in table shown above.

18
 Software Project Planning
The procedure for the calculation of UFP in mathematical
form is given below:
5 3
UFP   Z ij wij
i 1 J 1
Where i indicate the row and j indicates the column of Table 1

Wij : It is the entry of the ith row and jth column of the table 1
Zij : It is the count of the number of functional units of Type i that
have been classified as having the complexity corresponding to
column j. 19
 Software Project Planning

Organizations that use function point methods develop a criterion

for determining whether a particular entry is Low, Average or High.
Nonetheless, the determination of complexity is somewhat
subjective.

FP = UFP * CAF

Where CAF is complexity adjustment factor and is equal to [0.65 +

0.01 x ΣFi]. The Fi (i=1 to 14) are the degree of influence and are
based on responses to questions noted in table 3.

20
 Software Project Planning
Table 3 : Computing function points.
Rate each factor on a scale of 0 to 5.
0 1 2 3 4 5

No Incidental Moderate Average Significant Essential

Influence
Number of factors considered ( Fi )
1. Does the system require reliable backup and recovery ?
2. Is data communication required ?
3. Are there distributed processing functions ?
4. Is performance critical ?
5. Will the system run in an existing heavily utilized operational environment ?
6. Does the system require on line data entry ?
7. Does the on line data entry require the input transaction to be built over multiple screens or operations ?
8. Are the master files updated on line ?
9. Is the inputs, outputs, files, or inquiries complex ?
10. Is the internal processing complex ?
11. Is the code designed to be reusable ?
12. Are conversion and installation included in the design ?
13. Is the system designed for multiple installations in different organizations ?
14. Is the application designed to facilitate change and ease of use by the user ? 21
 Software Project Planning
Functions points may compute the following important metrics:
Productivity = FP / persons-months
Quality = Defects / FP
Cost = Rupees / FP
Documentation = Pages of documentation per FP

These metrics are controversial and are not universally acceptable.

There are standards issued by the International Functions Point User
Group (IFPUG, covering the Albrecht method) and the United
Kingdom Function Point User Group (UFPGU, covering the MK11
method). An ISO standard for function point method is also being
developed.

22
 Software Project Planning
Example: 4.1

Consider a project with the following functional units:

Number of user inputs = 50
Number of user outputs = 40
Number of user enquiries = 35
Number of user files = 06
Number of external interfaces = 04
Assume all complexity adjustment factors and weighting factors are
average. Compute the function points for the project.

23
 Software Project Planning
Solution
We know
5 3
UFP   Z ij wij
i 1 J 1

UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7
= 200 + 200 + 140 + 60 + 28 = 628
CAF = (0.65 + 0.01 ΣFi)
= (0.65 + 0.01 (14 x 3)) = 0.65 + 0.42 = 1.07
FP = UFP x CAF
= 628 x 1.07 = 672
24
 Software Project Planning

Example:4.2
An application has the following:
10 low external inputs, 12 high external outputs, 20 low
internal logical files, 15 high external interface files, 12
average external inquiries, and a value of complexity
adjustment factor of 1.10.
What are the unadjusted and adjusted function point counts ?

25
 Software Project Planning
Solution
Unadjusted function point counts may be calculated using
as:
5 3
UFP   Z ij wij
i 1 J 1
= 10 x 3 + 12 x 7 + 20 x 7 + 15 + 10 + 12 x 4
= 30 + 84 +140 + 150 + 48
= 452
FP = UFP x CAF
= 452 x 1.10 = 497.2.

26
 Software Project Planning
Example: 4.3
Consider a project with the following parameters.
(i) External Inputs:
(a) 10 with low complexity
(b)15 with average complexity
(c) 17 with high complexity
(ii) External Outputs:
(d)6 with low complexity
(e) 13 with high complexity
(iii) External Inquiries:
(a) 3 with low complexity
(b) 4 with average complexity
(c) 2 high complexity
27
 Software Project Planning
(iv) Internal logical files:
(a) 2 with average complexity
(b)1 with high complexity
(v) External Interface files:
(c) 9 with low complexity
In addition to above, system requires
i. Significant data communication
ii. Performance is very critical
iii. Designed code may be moderately reusable
iv. System is not designed for multiple installation in different
organizations.
Other complexity adjustment factors are treated as average. Compute
the function points for the project.
28
 Software Project Planning
Solution: Unadjusted function points may be counted using table 2
Functional Count Complexity Complexity Functional
Units Totals Unit Totals
External 10 Low x 3 = 30
Inputs 15 Average x 4 = 60
(EIs) 17 High x 6 = 102 192
External 6
Low x 4 = 24
Outputs 0 Average x 5 = 0
(EOs) 13 High x 7 = 91 115

External 3
Low x 3 = 9
Inquiries 4 Average x 4 = 16
(EQs) 2 High x 6 = 12 37

External 0 Low x 7 = 0
logical 2 Average x 10 = 20
Files (ILFs) 1 High x 15 = 15 35
External 9
Low x 5 = 45
Interface 0 Average x 7 = 0
Files (EIFs) 0 High x 10 = 0 45

424
Total Unadjusted Function Point Count
29
 Software Project Planning
14

 F  3+4+3+5+3+3+3+3+3+3+2+3+0+3=41
i 1
i

CAF = (0.65 + 0.01 x ΣFi)

= (0.65 + 0.01 x 41)
= 1.06
FP = UFP x CAF
= 424 x 1.06
= 449.44

Hence FP = 449
30