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.

2
 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

3
 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 Planning Project
scheduling

4
 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;

4. /*This function sorts array x in ascending order */
• If LOC is simply a count of 5. If (n<2) return 1;
the number of lines then 6. for (i=2; i<=n; i++)
7. {
figure shown below contains 8. im1=i-1;
18 LOC . 9. for (j=1; j<=im; j++)
10. if (x[i] < x[j])
11. {
12. Save = x[i];
• When comments and blank 13. x[i] = x[j];
lines are ignored, the 14. x[j] = save;
15. }
program in figure 2 shown 16. }
below contains 17 LOC. 17. return 0;
18. }

5
 Software Project Planning

Growth of Lines of Code (LOC)

2,500,000

Total LOC ("wc -l") -- development releases

Total LOC ("wc -l") -- stable releases
2,000,000
Total LOC uncommented -- development releases
Total LOC uncommented -- stable releases
1,500,000
Total LOC

1,000,000

500,000

0
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001

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
applications
Inputs ILF
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
External logical files (ILF) 7 10 15
External Interface files (EIF) 5 7 10

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 = ∑∑ Zij 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.
LOCs of an application can be estimated from FPs. That is, they are
interconvertible. This process is known as backfiring. For example,
1 FP is equal to about 100 lines of COBOL code. 22
LOC Per Function Point

Language Average Median Low High

Ada 154 -- 104 205
Assembler 337 315 91 694
C 162 109 33 704
C++ 66 53 29 178
COBOL 77 77 14 400
Java 55 53 9 214
PL/1 78 67 22 263
Visual Basic 47 42 16 158

www.qsm.com/?q=resources/function-point-languages-table/index.html

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 = ∑∑ Zij 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 = ∑∑ Zij 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 highcomplexity
(ii) External Outputs:
(a)6 with low complexity
(b)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:
(a) 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
i=1
i
= 3+4+3+5+3+3+3+3+3+3+2+3+0+3=41

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
Example
Compute the function point, productivity, documentation, cost per
function for the following data:
1.Number of user inputs = 24
2.Number of user outputs = 46
3.Number of inquiries = 8
4.Number of files = 4
5.Number of external interfaces = 2
6.Effort = 36.9 pm (Person-Months)
7.Technical documents = 265 pages
8.User documents = 122 pages
9.Cost = $7744/ month
10.Various processing complexity factors are: significant, no
influence, no influence, Average, Average, Essential, Significant,
Significant, Average, Average, Moderate, Moderate, Significant,
Essential.

31
Function Point (FP) Line of Code (LOC)

Function Point metric is specification-

LOC metric is based on analogy.
based.
Function Point metric is language
LOC metric is dependent on language.
independent.

Function Point metric is user-oriented. LOC metric is design-oriented.

Function Point metric is extendible to

It is changeable to FP (i.e, backfiring)
Line of Code.
Function Point is used for data LOC is used for calculating the size of
processing systems the computer program
LOC is used for calculating and
Function Point can be used to portray
comparing the productivity of
the project time
programmers.

32
Software Project Planning
Relative Cost of Software Phases

31
 Software Project Planning

Cost to Detect and Fix Faults

Relative Cost to detect and correct fault

200
180
160
140
120
100 Cost
80
60
40
20
0
Req Des I nt

32
 Software Project Planning
Cost Estimation
A number of estimation techniques have been developed and are
having following attributes in common :
➢ Project scope must be established in advance
➢ Software metrics are used as a basis from which estimates are made
➢ The project is broken into small pieces which are estimated individually

To achieve reliable cost and schedule estimates, a number of options

arise:
➢ Delay estimation until late in project
➢ Use simple decomposition techniques to generate project cost and
schedule estimates
➢ Develop empirical models for estimation
➢ Acquire one or more automated estimation tools

33
 Software Project Planning

MODELS

Static, Single Static,

Variable Multivariable
Models Models

34
 Software Project Planning
Static, Single Variable Models
Methods using this model use an equation to estimate the desired
values such as cost, time, effort, etc. They all depend on the same
variable used as predictor (say, size). An example of the most
The Software Engineering
common equations is :
Laboratory of the University of
C=a Lb (i) Maryland has established a
C is the cost, L is the size and a,b are constants model, SEL model

E = 1.4 L0.93
DOC = 30.4 L0.90
D = 4.6 L0.26
Effort (E in Person-months), documentation (DOC, in number of
pages) and duration (D, in months) are calculated from the number
of lines of code (L, in thousands of lines) used as a predictor.
35
• The constants a and b are derived from the historical
data of the organization. Since a and b depend on the
local development environment, these models are not
transportable to different organizations.

38
 Software Project Planning
Static, Multivariable Models
These models are depend on several variables representing various
aspects of the software development environment, for example
method used, user participation, customer oriented changes, memory
constraints, etc.
E = 5.2 L0.91 Model developed by Waltson and
Felix provide relationship between
D = 4.1 L0.36 LOC and effort

The productivity index uses 29 variables which are found to be

highly correlated to productivity as follows:
29
 = ∑Wi X i
i=1
where Wi is a factor weight for the ith variable and Xi={-1,0,+1}.
The estimator gives Xi depending on whether the variable
36
decreases, has no effect, or increases the productivity resp.
 Software Project Planning

Example: 4.4

Compare the Walston-Felix model with the SEL model on a

software development expected to involve 8 person-years of effort.

(a) Calculate the number of lines of source code that can be

produced.
(b)Calculate the duration of the development.
(c)Calculate the productivity in LOC/PY

(d)Calculate the average manning

37
 Software Project Planning
Solution
The amount of manpower involved = 8 PY = 96 person-months
(a) Number of lines of source code can be obtained by reversing equation to
give:

L = (E/a)1/b
L(SEL) = (96/1.4)1/0.93 = 94264LOC=94.264KLOC

L(SEL) = (96/5.2)1/0.91 = 24632 LOC=24.632KLOC.

38
 Software Project Planning
(b) Duration in months can be calculated by means of equation
D(SEL) = 4.6 (L)0.26
= 4.6 (94.264)0.26 = 15 months
D(W-F) = 4.1 L0.36
= 4.1(24.632)0.36 = 13 months
(c) Productivity is the lines of code produced per person/month (year)

94264
P(SEL) = = 11783 LOC / Person − Years
8

24632
P(W − F ) = = 3079 LOC / Person − Years
8

39
 Software Project Planning

(d) Average manning is the average number of persons required per

month in the project.

96 P − M
M (SEL) = = 6.4Persons
15M

96 P − M
M (W − F ) = = 7.4Persons
13M

If we look at the value of “L”, it seems that SEL can produce four
times as much software as IBM for the same manpower and time
scale.
40
 Software Project Planning

The Constructive Cost Model (COCOMO)

Constructive Cost model
(COCOMO)

Basic Intermediate Detailed

Model proposed by
B. W. Boehm’s
through his book
Software Engineering Economics in 1981
41
 Software Project Planning

COCOMO applied to

Semidetached
Organic mode Embedded
mode mode

COCOMO is hierarchy of software cost estimation models, which

include basic, intermediate and detailed sub models.
COCOMO- COnstructive Cost MOdel
42
 Software Project Planning
Mode Project size Nature of Project Innovation Deadline of Development
the project Environment

Organic Typically Small size project, experienced Little Not tight Familiar & In
developers in the familiar house
2-50 KLOC
environment. For example, pay
roll, inventory projects etc.

Semi Typically Medium size project, Medium Medium Medium Medium

detached size team, Average previous
50-300 KLOC
experience on similar project.
For example: Utility systems
like compilers, database
systems, editors etc.

Embedded Typically over Large project, Real time Significant Tight Complex
systems, Complex interfaces, Hardware/
300 KLOC
Very little previous experience. customer
For example: ATMs, Air Traffic Interfaces
Control etc. required

Table 4: The comparison of three COCOMO modes

43
 Software Project Planning

Basic Model
Basic COCOMO model takes the form

E = a (KLOC)bb
b

D = cb (E) db

where E is effort applied in Person-Months, and D is the

development time in months. The coefficients ab, bb, cb and db are
given in table 4 (a).

44
 Software Project Planning

Software ab bb cb db
Project

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Table 4(a): Basic COCOMO coefficients

45
 Software Project Planning

When effort and development time are known, the average staff size
to complete the project may be calculated as:
E
Average staff size (SS) = Persons
D

When project size is known, the productivity level may be

calculated as:
KLOC
Productivity (P) = KLOC / PM
E

46
 Software Project Planning

Example: 4.5

Suppose that a project was estimated to be 400 KLOC.

Calculate the effort and development time for each of the three
modes i.e., organic, semidetached and embedded.

47
 Software Project Planning
Solution
The basic COCOMO equation take the form:
bb
E = ab (KLOC)
D = cb (KLOC) d b
Estimated size of the project = 400 KLOC
(i) Organic mode
E = 2.4(400)1.05 = 1295.31 PM
D = 2.5(1295.31)0.38 = 38.07 PM

48
 Software Project Planning

(ii) Semidetached mode

E = 3.0(400)1.12 = 2462.79 PM
D = 2.5(2462.79)0.35 = 38.45 PM

(iii) Embedded mode

E = 3.6(400)1.20 = 4772.81 PM
D = 2.5(4772.8)0.32 = 38 PM

49
 Software Project Planning

Example: 4.6

A project size of 200 KLOC is to be developed. Software

development team has average experience on similar type of
projects. The project schedule is not very tight. Calculate the effort,
development time, average staff size and productivity of the project.

50
 Software Project Planning
Solution

The semi-detached mode is the most appropriate mode; keeping in

view the size, schedule and experience of the development team.

Hence E = 3.0(200)1.12 = 1133.12 PM

D = 2.5(1133.12)0.35 = 29.3 PM

E
Average staff size (SS) = Persons
D

1133.12
= = 38.67Persons
29.3

51
 Software Project Planning

KLOC 200
Productivity = = = 0.1765 KLOC / PM
E 1133.12

P = 176 LOC / PM

52
 Software Project Planning
Intermediate Model
Cost drivers
(i) Product Attributes
➢ Required s/w reliability
➢ Size of application database
➢Complexity of the product
(ii) Hardware Attributes
➢ Run time performance constraints
➢ Memory constraints
➢ Virtual machine volatility
➢ Turnaround time

53
 Software Project Planning
(iii) Personal Attributes
➢ Analyst capability
➢ Programmer capability
➢ Application experience
➢ Virtual m/c experience
➢ Programming language experience
(iv) Project Attributes
➢ Modern programming practices
➢ Use of software tools
➢ Required development Schedule

54
 Software Project Planning
Multipliers of different cost drivers
Cost Drivers RATINGS
Very low Low Nominal High Very Extra
high high
Product Attributes

RELY 0.75 0.88 1.00 1.15 1.40 --

DATA -- 0.94 1.00 1.08 1.16 --

CPLX 0.70 0.85 1.00 1.15 1.30 1.65

Computer Attributes

TIME -- -- 1.00 1.11 1.30 1.66

STOR -- -- 1.00 1.06 1.21 1.56

VIRT -- 0.87 1.00 1.15 1.30 --

TURN -- 0.87 1.00 1.07 1.15 --

55
 Software Project Planning
Cost Drivers RATINGS
Very low Low Nominal High Very Extra
high high
Personnel Attributes

ACAP 1.00 0.86 0.71 --

1.46 1.19
AEXP --
1.29 1.13 1.00 0.91 0.82
PCAP 0.86 0.70 --
1.42 1.17 1.00
VEXP -- --
1.21 1.10 1.00 0.90
LEXP 1.14 1.07 1.00 0.95 -- --
Project Attributes

MODP --
1.24 1.10 1.00 0.91 0.82
TOOL 1.24 1.10 1.00 0.91 0.83 --
SCED
1.23 1.08 1.00 1.04 1.10 --

Table 5: Multiplier values for effort calculations

56
• Effort adjustment factor EAF is calculated using
multiplying factors for all 15 cost drivers.

• Typical value ranges from 0.9 to 1.4

60
 Software Project Planning
Intermediate COCOMO equations
E = a (KLOC)bi * EAF
i

D = ci (E) d i
Project ai bi ci di

Organic 3.2 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 2.8 1.20 2.5 0.32

Table 6: Coefficients for intermediate COCOMO

57
 Software Project Planning
Detailed COCOMO Model
Detailed COCOMO

Phase-Sensitive Three level product

effort multipliers hierarchy

Cost Modules,
drivers design subsystem
& test System level
Manpower allocation for
each phase
58
 Software Project Planning
Principle of the effort estimate
Size equivalent
As the software might be partly developed from software already
existing (that is, re-usable code), a full development is not always
required. In such cases, the parts of design document (DD%), code
(C%) and integration (I%) to be modified are estimated. Then, an
adjustment factor, A, is calculated by means of the following
equation.
A = 0.4 DD + 0.3 C + 0.3 I
The size equivalent is obtained by
S (equivalent) = (S x A) / 100
E p = p E
Dp =  p D
61
 Software Project Planning
Lifecycle Phase Values of p
Mode & Code Plan & System Detailed Module Integration
Size Requirements Design Design Code & Test & Test

Organic Small
0.06 0.16 0.26 0.42 0.16
S≈2
Organic
0.06 0.16 0.24 0.38 0.22
medium S≈32
Semidetached
0.07 0.17 0.25 0.33 0.25
medium S≈32
Semidetached
0.07 0.17 0.24 0.31 0.28
large S≈128
Embedded
0.08 0.18 0.25 0.26 0.31
large S≈128
Embedded
extra large 0.08 0.18 0.24 0.24 0.34
S≈320

Table 7 : Effort and schedule fractions occurring in each phase of the lifecycle

62
 Software Project Planning
Lifecycle Phase Values of p
Mode & Code Plan & System Detailed Module Code Integration
Size Requirements Design Design & Test & Test

Organic Small
0.10 0.19 0.24 0.39 0.18
S≈2
Organic
0.12 0.19 0.21 0.34 0.26
medium S≈32
Semidetached
0.20 0.26 0.21 0.27 0.26
medium S≈32
Semidetached
0.22 0.27 0.19 0.25 0.29
large S≈128
Embedded
0.36 0.36 0.18 0.18 0.28
large S≈128
Embedded
extra large 0.40 0.38 0.16 0.16 0.30
S≈320

Table 7 : Effort and schedule fractions occurring in each phase of the lifecycle

63
 Software Project Planning

Distribution of software life cycle:

1. Requirement and product design
(a)Plans and requirements
(b)System design
2. Detailed Design
(a) Detailed design
3. Code & Unit test
(a) Module code & test
4. Integrate and Test
(a) Integrate & Test

64
 Software Project Planning

Example: 4.7
A new project with estimated 400 KLOC embedded system has to be
developed. Project manager has a choice of hiring from two pools of
developers: Very highly capable with very little experience in the
programming language being used
Or

Developers of low quality but a lot of experience with the programming

language. What is the impact of hiring all developers from one or the
other pool ?

65
 Software Project Planning
Solution
This is the case of embedded mode and model is intermediate
COCOMO.
Hence E = ai (KLOC) d i
= 2.8 (400)1.20 = 3712 PM

Case I: Developers are very highly capable with very little experience
in the programming being used.

EAF = 0.70 x 1.14 = 0.798

E = 3712 x .798 = 2962.176 PM
D = 2.5 (2962)0.32 = 32.2 M

66
 Software Project Planning

Case II: Developers are of low quality but lot of experience with the
programming language being used.

EAF = 1.29 x 0.95 = 1.22

E = 3712 x 1.22 = 4528 PM
D = 2.5 (4528)0.32 = 36.9 M

Case II requires more effort and time. Hence, low quality developers
with lot of programming language experience could not match with
the performance of very highly capable developers with very litter
experience.

67
 Software Project Planning
Example: 4.8
Consider a project to develop a full screen editor. The major components
identified are:
I. Screen edit
II. Command Language Interpreter
III. File Input & Output
IV. Cursor Movement
V. Screen Movement
The size of these are estimated to be 4k, 2k, 1k, 2k and 3k delivered source code
lines. Use COCOMO to determine
1. Overall cost and schedule estimates (assume values for different cost
drivers, Required software reliability is high, Product complexity is
high, Analyst capability is high, Programming language experience
is low, others are nominal)
2. Cost & Schedule estimates for different phases. 68
 Software Project Planning

Solution

Size of five modules are:

Screen edit = 4 KLOC

Command language interpreter = 2 KLOC
File input and output = 1 KLOC
Cursor movement = 2 KLOC
Screen movement = 3 KLOC
Total = 12 KLOC

69
 Software Project Planning

i. Required software reliability is high, i.e.,1.15

ii. Product complexity is high, i.e.,1.15

iii. Analyst capability is high, i.e.,0.86

iv. Programming language experience is low,i.e.,1.07

v. All other drivers are nominal

EAF = 1.15x1.15x0.86x1.07 = 1.2169

70
 Software Project Planning

(a) The initial effort estimate for the project is obtained from the
following equation

E = ai (KLOC)bi x EAF
= 3.2(12)1.05 x 1.2169 = 52.91 PM
Development time D = Ci(E)di
= 2.5(52.91)0.38 = 11.29 M
(b) Using the following equations and referring Table 7, phase wise
cost and schedule estimates can be calculated.
E p = p E
Dp =  p D

71
 Software Project Planning

Since size is only 12 KLOC, it is an organic small model. Phase wise

effort distribution is given below:
Plan & Requirement =0.06 x 52.91 =3.1746 PM
System Design = 0.16 x 52.91 = 8.465 PM
Detailed Design = 0.26 x 52.91 = 13.756 PM
Module Code & Test = 0.42 x 52.91 = 22.222 PM
Integration & Test = 0.16 x 52.91 = 8.465 Pm
Now Phase wise development time duration is
Plan & Requirement =0.10 x 11.29 = 1.129 M
System Design = 0.19 x 11.29 = 2.145 M
Detailed Design = 0.24 x 11.29 = 2.709 M
Module Code & Test = 0.39 x 11.29 = 4.403 M
Integration & Test = 0.18 x 11.29 = 2.032 M 72