Software Project

Management

1
Introduction
 Many software projects fail:
 due to faulty project
management practices:
 It is important to learn different
aspects of software project
management.

2
Introduction
 Goal of software project
management:
 enable a group of engineers to work
efficiently towards successful
completion of a software project.

3
Responsibility of project
managers
 Project proposal writing,
 Project cost estimation,
 Scheduling,
 Project staffing,
 Project monitoring and control,
 Software configuration management,
 Risk management,
 Managerial report writing and presentations, etc.

4
Question

 What are the necessary skills a project

manager should have?
a) Knowledge of project management techniques
b)Decision taking capabilities.
c) Previous experience in managing similar
projects.
d)All of above

5
Introduction
 A project manager’s activities
are varied.
 can be broadly classified into:
 project planning,
 project monitoring and control
activities.
6
Project Planning

 Once a project is found to be

feasible,
 project managers undertake project
planning.

7
Project Planning Activities

 Estimation:
 Effort, cost, resource, and project duration
 Project scheduling:
 Staff organization:
 staffing plans
 Risk handling:
 identification, analysis, and abatement
procedures
 Miscellaneous plans:
 quality assurance plan, configuration
management plan, etc.
8
Project planning

 Requires utmost care and attention ---

commitments to unrealistic time and
resource estimates result in:
 irritating delays.
 customer dissatisfaction
 adverse affect on team morale
 poor quality work
 project failure.

9
Sliding Window Planning

 Involves project planning over

several stages:
 protects managers from making big
commitments too early.
 More information becomes available
as project progresses.
 Facilitates accurate planning
10
SPMP Document

 After planning is complete:

 Document the plans:
 in a Software Project
Management Plan(SPMP)
document.

11
Organization of SPMP Document

 Introduction (Objectives,Major Functions,Performance Issues,Management and Technical

Constraints)

 Project Estimates (Historical Data,Estimation Techniques,Effort, Cost, and Project Duration Estimates)
 Project Resources Plan (People,Hardware and Software,Special Resources)
 Schedules (Work Breakdown Structure,Task Network, Gantt Chart Representation,PERT Chart
Representation)

 Risk Management Plan (Risk Analysis,Risk Identification,Risk Estimation, Abatement

Procedures)

 Project Tracking and Control Plan

 Miscellaneous Plans(Process Tailoring,Quality Assurance)

12
Question

 Which technique is used to plan the

project is several stages?
a)Project estimation planning
b)Sliding window planning
c)Project Documentation Plan
d)None of above

13
Software Cost Estimation

 Determine size of the product.

 From the size estimate,
 determine the effort needed.
 From the effort estimate,
 determine project duration, and cost.

14
Software Cost Estimation

Effort Cost
Estimation Estimation

Size Staffing
Estimation Estimation

Duration
Estimation Scheduling

15
Software Size Metrics

 LOC (Lines of Code):

 Simplest and most widely used
metric.
 Comments and blank lines should
not be counted.

16
Disadvantages of Using LOC

 Size can vary with coding style.

 Focuses on coding activity alone.
 Correlates poorly with quality and
efficiency of code.
 Penalizes higher level programming
languages, code reuse, etc.

17
Disadvantages of Using LOC
(cont...)

 Measures lexical/textual complexity

only.
 does not address the issues of
structural or logical complexity.
 Difficult to estimate LOC from
problem description.
 So not useful for project planning
18
Function Point Metric

 Overcomes some of the shortcomings of the

LOC metric
 Proposed by Albrecht in early 80’s:
 The function point metric is based on the
idea that a software product supporting
many features would certainly be of larger
size than a product with less number of
features.
19
Function Point Metric
 Input:
 A set of related inputs is counted as one input.
 Output:
 A set of related outputs is counted as one output.
 Inquiries:
 Each user query type is counted.
 Files:
 Files are logically related data and thus can be data
structures or physical files.
 Interface:
 Data transfer to other systems.

20
Question

 Which factor we have to evaluate first to

estimate efforts of the software project?
a)Cost Estimation
b)Duration Estimation
c)Size Estimation
d)Staffing Estimation

21
Function point (FP) metric
computation

 Step 1: Compute the unadjusted function point

(UFP) using a heuristic expression.
 Step 2: Refine UFP to reflect the actual
complexities of the different parameters used in
UFP computation.
 Step 3: Compute FP by further refining UFP to
account for the specific characteristics of the
project that can influence the entire
development effort.

22
Step 1: UFP computation

 The unadjusted function points (UFP) is computed as

the weighted sum of five characteristics of a product as
shown in the following expression.
 UFP = (Number of inputs)*4 + (Number of
outputs)*5 + (Number of inquiries)*4 + (Number of
files)*10 + (Number of interfaces)*10

23
Step 2: Refine parameters
 The complexity of each parameter is graded into three
broad categories—simple, average, or complex.

24
Step 3: Refine UFP based on complexity of the
overall project

 Albrecht identified 14 parameters that can influence the

development effort.
 Each of these 14 parameters is assigned a value from 0
(not present or no influence) to 6 (strong influence).
 The resulting numbers are summed, yielding the total
degree of influence (DI).
 DI = 14 * Average No. of influence
 TCF (technical complexity factor) = (0.65+0.01*DI)
 FP = UFP*TCF

25
list of these Parameters

26
Question

 How many steps are there to estimate the

Function Point?
a)2
b)3
c)5
d)6

27
Example
Determine the function point measure of the size of the following supermarket
software. A supermarket needs to develop the following software to
encourage regular customers. For this, the customer needs to supply his/her
residence address, telephone number, and the driving license number. Each
customer who registers for this scheme is assigned a unique customer number
(CN) by the computer. Based on the generated CN, a clerk manually prepares
a customer identity card after getting the market manager’s signature on it. A
customer can present his customer identity card to the check out staff when
he makes any purchase. In this case, the value of his purchase is credited
against his CN. At the end of each year, the supermarket intends to award
surprise gifts to 10 customers who make the highest total purchase over the
year. Also, it intends to award a 22 caret gold coin to every customer whose
purchase exceeded Rs. 10,000. The entries against the CN are reset on the
last day of every year after the prize winners’ lists are generated. Assume that
various project characteristics determining the complexity of software
development to be average.
28
 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.

29
Function Point Metric (CONT.)

 Suffers from a major drawback:

 the size of a function is considered to be
independent of its complexity.
 Extend function point metric:
 Feature Point metric:
 considers an extra parameter:
 Algorithm Complexity.

30
Function Point Metric (CONT.)

 Proponents claim:
 FP is language independent.
 Size can be easily derived from problem
description
 Opponents claim:
 it is subjective --- Different people can come
up with different estimates for the same
problem.
31
Project Estimation
Technique

 Three main approaches to

estimation:
 Empirical
 Heuristic
 Analytical

32
Project Estimation Technique

 Empirical techniques:
 an educated guess based on past experience.
 Heuristic techniques:
 assume that the characteristics to be
estimated can be expressed in terms of
some mathematical expression.
 Analytical techniques:
 derive the required results starting from
certain simple assumptions.

33
Empirical Size Estimation
Techniques
 Expert Judgement:
 An euphemism for guess made by
an expert.
 Suffers from individual bias.
 Delphi Estimation:
 overcomes some of the problems of
expert judgement.

34
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.

35
Delphi Estimation:

 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.

36
Delphi Estimation:

 Experts re-estimate.
 Experts never meet each other
 to discuss their viewpoints.

37
Heuristic Estimation Techniques

 Single Variable Model:

 Parameter to be Estimated=C1(Estimated
Characteristic)d1
 Multivariable Model:
 Assumes that the parameter to be
estimated depends on more than one
characteristic.
 Parameter to be Estimated=C1(Estimated
Characteristic)d1+ C2(Estimated Characteristic)d2+…
 Usually more accurate than single variable
models.
38
COCOMO Model

 COCOMO (COnstructive COst MOdel)

proposed by Boehm.
 Divides software product
developments into 3 categories:
 Organic
 Semidetached
 Embedded

39
COCOMO Product classes

 Roughly correspond to:

 application, utility and system programs
respectively.
 Data processing and scientific programs are
considered to be application programs.
 Compilers, linkers, editors, etc., are utility
programs.
 Operating systems and real-time system
programs, etc. are system programs.

40
Elaboration of Product
classes
 Organic:
 Relatively small groups
 working to develop well-understood applications.
 Semidetached:
 Project team consists of a mixture of
experienced and inexperienced staff.
 Embedded:
 The software is strongly coupled to complex
hardware, or real-time systems.

41
COCOMO Model (CONT.)

 For each of the three product categories:

 From size estimation (in KLOC), Boehm provides
equations to predict:
 project duration in months
 effort in programmer-months
 Boehm obtained these equations:
 examined historical data collected from a large
number of actual projects.

42
COCOMO Model (CONT.)

 Software cost estimation is done

through three stages:
 Basic COCOMO,
 Intermediate COCOMO,
 Complete COCOMO.

43
Basic COCOMO Model (CONT.)

 Gives only an approximate estimation:

 Effort = a1*(KLOC)a2
 Tdev = b1*(Effort)b2
 KLOC is the estimated kilo lines of source
code,
 a1,a2,b1,b2 are constants for different
categories of software products,
 Tdev is the estimated time to develop the
software in months,
 Effort estimation is obtained in terms of
person months (PMs).
44
Development Effort
Estimation
 Organic :
 Effort = 2.4 (KLOC)1.05 PM
 Semi-detached:
 Effort = 3.0(KLOC)1.12 PM
 Embedded:
 Effort = 3.6 (KLOC)1.20 PM
45
Development Time
Estimation
 Organic:
 Tdev = 2.5 (Effort)0.38 Months
 Semi-detached:
 Tdev = 2.5 (Effort)0.35 Months
 Embedded:
 Tdev = 2.5 (Effort)0.32 Months
46
Basic COCOMO Model (CONT.)

h ed
t ac
 Effort is Effort m ide
Se
somewhat d ded
m be ic
super-linear in E
Or ga
n

problem size.
Size

47
Basic COCOMO Model (CONT.)

 Development time
 sublinear function of
product size. Dev. Time
 When product size de
d
ta c he d
b ed mide
increases two times, 18 Months Em Se
 development time does
14 Months
not double. n ic
rga
O
 Time taken:
 almost same for all the 30K 60K
three product categories. Size

48
Basic COCOMO Model (CONT.)

 Development time does not

increase linearly with product size:
 For larger products more parallel
activities can be identified:
 can be carried out simultaneously by a
number of engineers.

49
Basic COCOMO Model (CONT.)

 Development time is roughly the same for

all the three categories of products:
 For example, a 60 KLOC program can be
developed in approximately 18 months
 regardless of whether it is of organic, semi-
detached, or embedded type.
 There is more scope for parallel activities for
system and application programs,
 than utility programs.

50
Example
 The size of an organic software product has
been estimated to be 32,000 lines of source
code.

 Effort = 2.4*(32)1.05 = 91 PM
 Nominal development time = 2.5*(91)0.38 = 14
months

51
Intermediate COCOMO

 Basic COCOMO model assumes

 effort and development time depend on
product size alone.
 However, several parameters affect effort
and development time:
 Reliability requirements
 Availability of CASE tools and modern facilities to
the developers
 Size of data to be handled

52
Intermediate COCOMO

 For accurate estimation,

 the effect of all relevant parameters
must be considered:
 Intermediate COCOMO model recognizes
this fact:
 refines the initial estimate obtained by the
basic COCOMO by using a set of 15 cost
drivers (multipliers).
53
Intermediate COCOMO
(CONT.)

 If modern programming practices

are used,
 initial estimates are scaled
downwards.
 If there are stringent reliability
requirements on the product :
 initial estimate is scaled upwards.
54
Intermediate COCOMO
(CONT.)

 Rate different parameters on a

scale of one to three:
 Depending on these ratings,
 multiply cost driver values with
the estimate obtained using the
basic COCOMO.

55
Intermediate COCOMO
(CONT.)

 Cost driver classes:

 Product: Inherent complexity of the product,
reliability requirements of the product, etc.
 Computer: Execution time, storage
requirements, etc.
 Personnel: Experience of personnel, etc.
 Development Environment: Sophistication of
the tools used for software development.

56
Intermediate COCOMO (CONT.)

 (i) Product attributes –

• Required software reliability extent
• Size of the application database
• The complexity of the product
 (ii) Hardware attributes –
• Run-time performance constraints
• Memory constraints
• The volatility of the virtual machine environment
• Required turnabout time

57
Intermediate COCOMO (CONT.)

 (iii) Personnel attributes –

• Analyst capability
• Software engineering capability
• Applications experience
• Virtual machine experience
• Programming language experience
 (iv) Project attributes –
• Use of software tools
• Application of software engineering methods
• Required development schedule
58
59
Example
 The size of Microprocessor communication
software product has been estimated to be
52,000 lines of source code.
 Calculate Efforts?

60
61
Shortcoming of basic and
intermediate COCOMO models

 Both models:
 consider a software product as a single
homogeneous entity:
 However, most large systems are made up of
several smaller sub-systems.
 Some sub-systems may be considered as organic
type, some may be considered embedded, etc.
 for some the reliability requirements may be high,
and so on.

62
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.

63
Complete COCOMO
Example
 A Management Information System (MIS) for an
organization having offices at several places
across the country:
 Database part (semi-detached)
 Graphical User Interface (GUI) part (organic)
 Communication part (embedded)
 Costs of the components are estimated
separately:
 summed up to give the overall cost of the system.

64
Question
 The size of software product has been estimated
to be 82,000 lines of source code and effort
adjustment factor is 2.41
 Calculate Efforts?

65
Staffing Level Estimation

 Number of personnel required during

any development project:
 not constant.
 Norden in 1958 analyzed many R&D
projects, and observed:
 Rayleigh curve represents the number of
full-time personnel required at any time.

66
Rayleigh Curve

 Rayleigh curve is Rayleigh Curve

specified by two

Effort
parameters:
 td the time at
which the curve
reaches its
maximum td
 K the total area Time
under the curve.
 L=f(K, td)
67
 Norden represented the Rayleigh curve by the following
equation:

 E is the effort required at time t. E is an indication of the

number of engineers (or the staffing level) at any
particular time during the duration of the project
 K is the area under the curve, and
 td is the time at which the curve attains its maximum
value.

68
Putnam’s Work:

 In 1976, Putnam studied the problem of

staffing of software projects:
 observed that the level of effort required in
software development efforts has a similar
envelope.
 found that the Rayleigh-Norden curve
 relates the number of delivered lines of code to
effort and development time.

69
Putnam’s Work (CONT.) :

70
Putnam’s Work (CONT.) :

 Ck=2 for poor development environment

 no methodology, poor documentation, and
review, etc.
 Ck=8 for good software development
environment
 software engineering principles used
 Ck=11 for an excellent environment

71
Rayleigh Curve

 Very small number of engineers are

needed at the beginning of a project
 carry out planning and specification.
 As the project progresses:
 more detailed work is required,
 number of engineers slowly increases
and reaches a peak.

72
Rayleigh Curve

 Putnam observed that:

 the time at which the Rayleigh curve
reaches its maximum value
 corresponds to system testing and product
release.
 After system testing,
 the number of project staff falls till product
installation and delivery.
73
Rayleigh Curve

 From the Rayleigh curve observe

that:
 approximately 40% of the area
under the Rayleigh curve is to the
left of td
 and 60% to the right.

74
Effect of Schedule Change
on Cost
 Using the Putnam's expression for L,
K=L3/(Ck3 * td4)
Or, K=C/td4
 For the same product size, C=L3/Ck3 is
a constant.
 Or, K1/K2 = td24/td14

75
Effect of Schedule Change on
Cost (CONT.)

 Observe:
 a relatively small compression in delivery
schedule
 can result in substantial penalty on human
effort.
 Also, observe:
 benefits can be gained by using fewer
people over a somewhat longer time span.

76
Example

 If the estimated development time is 1

year, then in order to develop the
product in 6 months,
 the total effort and hence the cost
increases 16 times.
 In other words,
 the relationship between effort and the
chronological delivery time is highly nonlinear.

77
Example

 The nominal effort and duration of a project

have been estimated to be 1000PM and 15
months. The project cost has been negotiated
to be Rs. 200,000,000. The needs the product
to be developed and delivered in 12 month
time. What should be the new cost to be
negotiated?

78
Effect of Schedule Change on
Cost (CONT.)

 Putnam model indicates extreme penalty

for schedule compression
 and extreme reward for expanding the
schedule.
 Putnam estimation model works
reasonably well for very large systems,
 but seriously overestimates the effort for
medium and small systems.

79
Effect of Schedule Change on
Cost (CONT.)

 Boehm observed:
 “There is a limit beyond which the
schedule of a software project cannot
be reduced by buying any more
personnel or equipment.”
 This limit occurs roughly at 75% of the
nominal time estimate.

80
Effect of Schedule Change
on Cost (CONT.)

 If a project manager accepts a customer

demand to compress the development
time by more than 25%
 very unlikely to succeed.
 every project has only a limited amount of parallel
activities
 sequential activities cannot be speeded up by hiring
any number of additional engineers.
 many engineers have to sit idle.

81
Example

 The nominal effort and duration of a project

have been estimated to be 15000PM and 54
months. The project cost has been negotiated
to be Rs. 400,000,000. The needs the product
to be developed and delivered in 40 month
time. What should be the new cost to be
negotiated?

82
Project scheduling
It involves deciding which tasks would be taken up
when. Activities undertaken:
1. Identify all the tasks needed to complete the project.
2. Break down large tasks into small activities.
3. Determine the dependency among different activities.
4. Establish the most likely estimates for the time durations
necessary to complete the activities.
5. Allocate resources to activities.
6. Plan the starting and ending dates for various activities.
7. Determine the critical path. A critical path is the chain of
activities that determines the duration of the project.
Work breakdown structure
 Work Breakdown Structure (WBS) is used to
decompose a given task set recursively into small
activities.
 The root of the tree is labelled by the problem
name.
 Each node of the tree is broken down into smaller
activities that are made the children of the node.
 Each activity is recursively decomposed into
smaller sub-activities until at the leaf level, the
activities requires approximately two weeks to
develop.
Work breakdown structure of
MIS problem
Activity networks and critical
path method
 WBS representation of a project is
transformed into an activity network by
representing activities identified in WBS
along with their interdependencies.
 An activity network shows the different
activities making up a project, their
estimated durations, and
interdependencies.
Activity network representation
of the MIS problem

Activity Predecessor Activity Duration (Days)

Specification - 15
Design Database Specification 45
Design GUI Part Specification 30
Write User Manual Specification 60
Code Database Design Database 105
Code GUI Part Design GUI Part 45
Integration Test Code Database, 120
Code GUI Part
Finish Integration Test, 0
Write User Manual

87
Activity network
representation of the MIS
problem
Example

89
Critical Path Method (CPM)
 The minimum time (MT) to complete the project is the
maximum of all paths from start to finish.
 The earliest start (ES) time of a task is the maximum of all
paths from the start to the task.
 The latest start time is the difference between MT and the
maximum of all paths from this task to the finish.
 The earliest finish time (EF) of a task is the sum of the
earliest start time of the task and the duration of the task.
 The latest finish (LF) time of a task can be obtained by
subtracting maximum of all paths from this task to finish from
MT.
 The slack time (ST) is LS – EF and equivalently can be
written as LF – EF.
Slack Time
 The slack time (or float time) is the total
time that a task may be delayed before it will
affect the end time of the project.
 The slack time indicates the “flexibility” in
starting and completion of tasks.
 A critical task is one with a zero slack time.
A path from the start node to the finish node
containing only critical tasks is called a
critical path.
Parameters for different tasks
of MIS Problem
Question

 What is slack time?

a: Total time that a task may be delayed before it will
affect the end time of the project.
B: The maximum of all paths from start to finish
C: The difference between MT and the maximum of all
paths from this task to the finish
D: The sum of the earliest start time of the task and the
duration of the task

93
CPM graph Example
Activity Predecessor Duration (in months)
A - 5
B A 4
C A 5
D B 6
E C 3
F D,E 4

94
CPM graph

B D

A F Finish
Start

C E

95
 Critical Path Calculation
MT
ES
(D)
EF ES : Earliest start time
MT(D): Maximum Time/Duration
Activity
EF : Earliest Finish Time
LS: Latest Start Time
LS SL LF
SL: Slack Time
LF: Latest Finish Time
Activity : Critical activity of the
project.
Formulae:
EF = ES + D
SL = LF – EF
LS = LF – MT (D)
ES = Predecessor’s EF
96
LF = successor’s LS
0 5 5

A 5 4 9
5 5 10
B
C

9 6 15
10 3 13
D 15 4 19
E
F

97
 SL = LF – EF
LS = LF – D
Start calculation from the finish (last) activity =
F
15 4 19 10 3 13 9 6 15

F E D

15 0 19 12 2 15 9 0 15

0 5 5
5 5 10 5 4 9
A
C B
0 0 5
7 2 12 5 0 9

98
Critical Paths
 From the given example, we have 2 paths:

B D

A F Finish
Start

C E
 A->B->D->F
 A->C->E->F

99
Critical Paths contd

 However, a critical path is the one which

has 0 Slack Time (SL)
 Therefore, out of the two paths,
 A->B->D->F path has 0 slack time.

0 5 5 5 4 9 9 6 15 15 4 19

A B D F

0 0 5 5 0 9 9 0 15 15 0 19

100
CPM Table:
Activity ES MT (D) EF LS SL LF
A 0 5 5 0 0 5
B 5 4 9 5 0 9
C 5 5 10 7 2 12
D 9 6 15 9 0 15
E 10 3 13 12 2 15
F 15 4 19 15 0 19

101
Gantt chart
 Used to allocate resources to activities
(resource planning).
The resources allocated to activities
include staff, hardware, and software.
 A Gantt chart is a special type of bar chart
where each bar represents an activity.
 The bars are drawn along a time line.
 The length of each bar is proportional to the
duration of time planned for the
corresponding activity.
Gantt chart for MIS
problem
PERT chart

 PERT (Program Evaluation and Review

Technique) charts consist of a network of
boxes and arrows.
 The boxes represent activities and the
arrows represent task dependencies.
 The boxes of PERT charts are usually
annotated with the pessimistic, likely, and
optimistic estimates for every task.
 Gantt chart representation of a project
schedule is helpful in planning the
utilization of resources, while PERT chart
is useful for monitoring the timely
progress of activities.
 Also, it is easier to identify parallel
activities in a project using a PERT chart.
PERT chart representation of
the MIS problem