Chapter 3

SOFTWARE PROJECT MANAGEMENT

Prepared by Dr. Ali Aliedani

• The main goal of software project management is to enable a group of developers to work effectively towards the
successful completion of a project.

RESPONSIBILITIES OF A SOFTWARE PROJECT MANAGER

We can broadly classify a project manager’s varied responsibilities into the following two major categories:
• Project planning is undertaken immediately after the feasibility study phase and before the starting of the requirements
analysis and specification phase.
Project planning involves estimating several characteristics of a project and then planning the project activities based on
these estimates made.
• Project monitoring and control are undertaken once the development activities start. The focus of project monitoring
and control activities is to ensure that the software development proceeds as per plan.

Three skills that are most critical to successful project management are the following:
• Knowledge of project management techniques.
• Decision taking capabilities.
• Previous experience in managing similar projects.
During project planning, the project manager performs the following Activities:
Estimation: The following project attributes are estimated.
• Cost: How much is it going to cost to develop the software product?
• Duration: How long is it going to take to develop the product?
• Effort: How much effort would be necessary to develop the product?
The effectiveness of all later planning activities such as scheduling and staffing are dependent on the accuracy with which
these three estimations have been made.

Scheduling: the schedules for manpower and other resources are developed.
Staffing: Staff organization and staffing plans are made.
Risk management: This includes risk identification,
analysis, and abatement planning.
Miscellaneous plans: This includes making several other
plans such as quality assurance plan,
and configuration management plan, etc.
3.3 METRICS FOR PROJECT SIZE ESTIMATION
3.3.1 Lines of Code (LOC)
❑ Simplest and most widely used metric.
❑ Comments and blank lines should not be counted.

Systematic guessing typically involves the following.

• The project manager divides the problem into modules, and each module into sub-modules and so on, until the LOC of the leaf-
level modules are small enough to be predicted.
• To be able to predict the LOC count for the various leaf-level modules sufficiently accurately, past experience in developing
similar modules is very helpful.

Disadvantages of LOC
✓ LOC is a measure of coding activity alone..
✓ LOC count depends on the choice of specific instructions:
✓ LOC measure correlates poorly with the quality and efficiency of the code.
✓ LOC metric penalizes use of higher-level programming languages and code reuse.
✓ LOC metric measures the lexical complexity of a program and does not address the more important issues of logical and
structural complexities.
✓ It is very difficult to accurately estimate LOC of the final program from problem specification.
3.3.2 Function Point (FP) Metric
One of the important advantages of the function point metric over the LOC metric is that it can easily be computed from the
problem specification itself.

The five functional units are divided in two categories:

• Internal Logical Files (ILF): related data or control information maintained within the system.
• External Interface files (EIF): related data or control information referenced by the system, but maintained within another
system.
• External Input (EI): An EI processes data or control information that comes from outside the system.
• 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
The procedure for the calculation of Unadjusted
Function Point (UFP) is given:
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.

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 ?
Example: 3.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.

Solution
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
Example:3.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 ?
Solution
UFP= 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.
Example: 3.3 In addition to above, system requires
Consider a project with the following parameters. i. Significant data communication
(i) External Inputs: ii. Performance is very critical
(a)10 with low complexity iii. Designed code may be moderately reusable
(b)15 with average complexity iv. System is not designed for multiple installation in different
organizations.
(c)17 with high complexity
Other complexity adjustment factors are treated as average.
(ii) External Outputs: Compute the function points for the project.
(a)6 with low complexity
(b)13 with high complexity Σ𝐹= 3+4+3+5+3+3+3+3+3+3+2+3+0+3=41
(iii) External Inquiries: CAF = (0.65 + 0.01 x ΣFi)
(a) 3 with low complexity = (0.65 + 0.01 x 41)
(b) 4 with average complexity = 1.06
(c) 2 high complexity FP = UFP x CAF
(iv) Internal logical files: = 424 x 1.06
(a)2 with average complexity = 449.44
(b)1 with high complexity Hence FP = 449
(v) External Interface files:
(a)9 with low complexity
PROJECT ESTIMATION TECHNIQUES
• Empirical estimation techniques
• Heuristic techniques
• Analytical estimation techniques

1. Empirical Estimation Techniques

• Empirical estimation techniques are essentially based on making an educated guess of the project parameters.

A- Expert Judgement:
❑ Experts divide a software product into component units: e.g. GUI, database module, data communication module, billing module, etc.
❑ Add up the guesses for each of the components.
❑ Suffers from individual bias.

B- Delphi Estimation:

❑ overcomes some of the problems of expert judgement.

❑ Team of Experts and a coordinator.
❑ Experts carry out estimation independently:
❑ mention the rationale behind their estimation.
❑ coordinator notes down any extraordinary rationale:
❑ circulates among experts.
❑ Experts re-estimate.
❑ Experts never meet each other to discuss their viewpoints.
 2. Heuristic Techniques
• Heuristic techniques assume that the relationships that exist among the different project parameters can be satisfactorily modelled using suitable mathematical
expressions.

A. COCOMO
COnstructive COst estimation MOdel (COCOMO) was proposed by Boehm [1981]. COCOMO prescribes a three stage process for project estimation. In the
first stage, an initial estimate is arrived at.

Basic COCOMO Model

Example: 3.5
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.

Solution
The semi-detached mode is the most appropriate mode; keeping in view the size, schedule and experience of the development
team.

E = 3.0(200)1.12 = 1133.12 PM
D = 2.5(1133.12)0.35 = 29.3 PM
 Intermediate COCOMO
z Basic COCOMO model assumes
y effort and development time depend on product size alone.
z However, several parameters affect effort and development time:
x Reliability requirements
x Availability of CASE tools and modern facilities to the developers
x Size of data to be handled
z For accurate estimation,
y the effect of all relevant parameters must be considered:
y Intermediate COCOMO model recognizes this fact:
x refines the initial estimate obtained by the basic COCOMO by using a set of 15 cost drivers (multipliers) (Effort Adjustment Factor).
Shortcoming of basic and intermediate COCOMO models
z Both models:
y consider a software product as a single homogeneous entity:
y However, most large systems are made up of several smaller sub-systems.
x Some sub-systems may be considered as organic type, some may be considered embedded, etc.
x for some the reliability requirements may be high, and so on.

Complete COCOMO
➢ Cost of each sub-system is estimated separately.
➢ Costs of the sub-systems are added to obtain total cost.
➢ Reduces the margin of error in the final estimate.

Complete COCOMO Example

➢ A Management Information System (MIS) for an organization having offices at several places across the country:
o Database part (semi-detached)
o Graphical User Interface (GUI) part (organic)
o Communication part (embedded)
➢ Costs of the components are estimated separately:
o summed up to give the overall cost of the system.
COCOMO-II
COCOMO 2 provides three models to arrive at increasingly accurate cost estimations. These can be used to estimate project
costs at different phases of the software product. As the project progresses, these models can be applied at the different stages
of the same project.

Application composition model

Table 7 (a): for screens

Table 7 (b): for reports

Example: 3.9
Consider a database application project with the following characteristics:
I. The application has 4 screens with 4 views each and 7 data tables for 3 servers and 4 clients.
II. The application may generate two report of 6 sections each from 07 data tables for two server and 3 clients.
There is 10% reuse of object points.
The developer’s experience and capability in the similar environment is low. The maturity of organization in terms of capability is also
low. Calculate the object point count, New object points and effort to develop such a project.
Solution
This project comes under the category of application composition estimation model.
Number of screens = 4 with 4 views each
Number of reports = 2 with 6 sections each
From Table 7 we know that each screen will be of medium complexity and each report will be difficult complexity.
Using Table 8 of complexity weights, we may calculate object point count.
= 4 x 2 + 2 x 8 = 24

Table 9 gives the low value of productivity (PROD) i.e. 7.