Software Project Planning

The overall goal of project planning is to

establish a pragmatic strategy for
controlling, tracking, and monitoring a
complex technical project.

Why?
So the end result gets done on time, with
quality!

1
Project Planning Task Set-I
 Establish project scope
 Determine feasibility
 Analyze risks
 Define required resources
 Determine require human resources
 Define reusable software resources
 Identify environmental resources

2
Project Planning Task Set-II
 Estimate cost and effort
 Decompose the problem
 Develop two or more estimates using size, function
points, process tasks or use-cases
 Reconcile the estimates
 Develop a project schedule
 Establish a meaningful task set
 Define a task network
 Use scheduling tools to develop a timeline chart
 Define schedule tracking mechanisms

3
Estimation
 Estimation of resources, cost, and schedule for
a software engineering effort requires
 experience
 access to good historical information (metrics)
 the courage to commit to quantitative predictions
when qualitative information is all that exists
 Estimation carries inherent risk and this risk
leads to uncertainty

4
Write it Down!

Project Scope Software

Estimates Project
Risks Plan
Schedule
Control strategy

5
To Understand Scope ...
 Understand the customers needs
 understand the business context
 understand the project boundaries
 understand the customer’s motivation
 understand the likely paths for change
 understand that ...

Even when you understand,

nothing is guaranteed!

6
What is Scope?
 Software scope describes
 the functions and features that are to be delivered to
end-users
 the data that are input and output
 the “content” that is presented to users as a
consequence of using the software
 the performance, constraints, interfaces, and
reliability that bound the system.
 Scope is defined using one of two techniques:
• A narrative description of software scope is developed
after communication with all stakeholders.
• A set of use-cases is developed by end-users.

7
Resources

8
Resources

 The second planning task is estimation of the resources

required to accomplish the software development effort.

 Each resource is specified with four characteristics:

description of the resource, a statement of availability,
time when the resource will be required, and duration of
time that the resource will be applied.

9
Resources
1. Human Resources
The planner begins by evaluating software scope and selecting
the skills required to complete development.
Both organizational position (e.g., manager, senior software
engineer) and specialty (e.g., telecommunications, database,
client-server) are specified.
For relatively small projects (a few person-months), a single
individual may perform all software engineering tasks, consulting
with specialists as required. For larger projects, the software team
may be geographically dispersed across a number of different
locations.
The number of people required for a software project can be
determined only after an estimate of development effort (e.g.,
person-months) is made.

10
Resources
2. Reusable Software Resources
Component-based software engineering (CBSE)
emphasizes reusability, i.e., the creation and reuse of
software building blocks, often called, components.
Bennatan [Ben00] suggests four software resource
categories that should be considered as planning proceeds:
 Off-the-shelf components
 Full-experience components.
 Partial-experience components
 New components
Ironically,
reusable software components are often
neglected during planning, only to become a paramount
concern later in the software process

11
Resources
3. Environmental Resources
The environment that supports a software project, often
called the software engineering environment (SEE),
incorporates hardware and software.
Hardware provides a platform that supports the tools
(software) required to produce the work products that are
an outcome of good software engineering practice.
When a computer-based system (incorporating
specialized hardware and software) is to be engineered, the
software team may require access to hardware elements
being developed by other engineering teams

12
Software Project Estimation
 To achieve reliable cost and effort estimates, a
number of options arise:
 Delay estimation until late in the project (obviously,
we can achieve 100 percent accurate estimates after
the project is complete!).
 Base estimates on similar projects that have already
been completed.
 Use relatively simple decomposition techniques to
generate project cost and effort estimates.
 Use one or more empirical models for software cost
and effort estimation

13
Estimation Techniques
 Past (similar) project experience
 Conventional estimation techniques
 task breakdown and effort estimates
 size (e.g., FP) estimates
 Empirical models
 Automated tools

14
Decomposition Techniques
1. Software Sizing
Predicated on …
 the degree to which the planner has properly estimated
the size of the product to be built
 the ability to translate the size estimate into human
effort, calendar time, and dollars (a function of the
availability of reliable software metrics from past
projects)
 the degree to which the project plan reflects the
abilities of the software team
 the stability of product requirements and the
environment that supports the software engineering
effort.
15
 Putnam and Myers [Put92] suggest four
different approaches to the sizing problem:

 “Fuzzy logic” sizing: This approach uses the

approximate reasoning techniques that are the
cornerstone of fuzzy logic. To apply this approach, the
planner must identify the type of application, establish its
magnitude on a qualitative scale, and then refine the
magnitude within the original range.

 Function point sizing: The planner develops estimates of

the information domain characteristics.
16
 Standard component sizing: Software is composed
of a number of different “standard components”. The
project planner estimates the number of occurrences
of each standard component and then uses historical
project data to estimate the delivered size per
standard component.

 Change sizing: This approach is used when a project

encompasses the use of existing software that must
be modified in some way as part of a project. The
planner estimates the number and type (e.g., reuse,
adding code, changing code, deleting code) of
modifications that must be accomplished.

17
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 18
Conventional Methods:
LOC/FP Approach
 compute LOC/FP using estimates of
information domain values
 use historical data to build estimates for
the project

19
 Example: LOC Approach

Average productivity for systems of this type = 620

LOC/pm.
Burdened labor rate =$8000 per month, the cost per
line of code is approximately $13.
Based on the LOC estimate and the historical
productivity data, the total estimated project cost is
$431,000
These slides are and
designed to accompany the
Software estimated
Engineering: A Practitioner’seffort is 54 person-
Approach, 7/e
(McGraw-Hill months.
2009). Slides copyright 2009 by Roger Pressman. 20
Example: FP Approach

The estimated number of FP is derived:

FPestimated = count-total 3 [0.65 + 0.01 3 S (Fi)]
FPestimated = 375
organizational average productivity = 6.5 FP/pm.
burdened labor rate = $8000 per month, approximately $1230/FP.
Based on the FP estimate and the historical productivity data, total
estimated project cost is $461,000 and estimated effort is 58
person-months.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 21
 Process-Based Estimation
Obtained from “process framework”

framework activities

application Effort required to

functions accomplish
each framework
activity for each
application function

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 22
 Process-Based Estimation Example

Based on an average burdened labor rate of $8,000

per month, the total estimated project cost is
$368,000 and the estimated effort is 46 person-
months.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 23
 Tool-Based Estimation

project characteristics

calibration factors

LOC/FP data

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 24
 Estimation with Use-Cases

Using 620 LOC/pm as the average productivity for

systems of this type and a burdened labor rate of
$8000 per month, the cost per line of code is
approximately $13. Based on the use-case estimate
and the historical productivity data, the total
estimated project cost is $552,000 and the
estimated effort is 68 person-months.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 25
 Empirical Estimation Models
General form:

exponent
effort = tuning coefficient * size

usually derived
as person-months empirically
of effort required derived

usually LOC but

may also be
function point
either a constant or
a number derived based
on complexity of project

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 26
 COCOMO-II
 COCOMO II is actually a hierarchy of
estimation models that address the following
areas:
• Application composition model. Used during the early
stages of software engineering, when prototyping of
user interfaces, consideration of software and system
interaction, assessment of performance, and evaluation
of technology maturity are paramount.
• Early design stage model. Used once requirements
have been stabilized and basic software architecture
has been established.
• Post-architecture-stage model. Used during the
construction of the software.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 27
 The Software Equation
A dynamic multivariable model

E = [LOC x B0.333/P]3 x (1/t4)

where
E = effort in person-months or person-years
t = project duration in months or years
B = “special skills factor”
P = “productivity parameter”

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 28
 Estimation for OO Projects-I
 Develop estimates using effort decomposition, FP analysis,
and any other method that is applicable for conventional
applications.
 Using object-oriented requirements modeling (Chapter 6),
develop use-cases and determine a count.
 From the analysis model, determine the number of key classes
(called analysis classes in Chapter 6).
 Categorize the type of interface for the application and develop
a multiplier for support classes:
 Interface type Multiplier
 No GUI 2.0
 Text-based user interface 2.25
 GUI 2.5
 Complex GUI 3.0

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 29
 Estimation for OO Projects-II
 Multiply the number of key classes (step 3) by the
multiplier to obtain an estimate for the number of support
classes.
 Multiply the total number of classes (key + support) by
the average number of work-units per class. Lorenz and
Kidd suggest 15 to 20 person-days per class.
 Cross check the class-based estimate by multiplying the
average number of work-units per use-case

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 30
 Estimation for Agile Projects
 Each user scenario (a mini-use-case) is considered separately
for estimation purposes.
 The scenario is decomposed into the set of software
engineering tasks that will be required to develop it.
 Each task is estimated separately. Note: estimation can be
based on historical data, an empirical model, or “experience.”
 Alternatively, the ‘volume’ of the scenario can be estimated in LOC,
FP or some other volume-oriented measure (e.g., use-case count).
 Estimates for each task are summed to create an estimate for
the scenario.
 Alternatively, the volume estimate for the scenario is translated into
effort using historical data.
 The effort estimates for all scenarios that are to be implemented
for a given software increment are summed to develop the effort
estimate for the increment.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 31
The Make-Buy Decision

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 32
Computing Expected Cost
expected cost =

(path probability) x (estimated path cost)

i i

For example, the expected cost to build is:

expected cost = 0.30 ($380K) + 0.70 ($450K)

build
= $429 K
similarly,

expected cost = $382K

reuse
expected cost = $267K
buy
expected cost = $410K
contr
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 33