SOFTWARE

PROJECT
MANAGEMENT
OBJECTIVES
Observations on Estimation

The Project Planning Process

Software Scope and Feasibility

Resources
• Human Resources
• Reusable Software Resources
• Environmental Resources

Work Breakdown Structure

Software Project Estimation

SOFTWARE PROJECT MANAGEMENT 2

OBJECTIVES
Decomposition Techniques
• Software Sizing
• Problem-Based Estimation
• Process-Based Estimation
• Estimation with Use Cases
• Reconciling Estimates

Empirical Estimation Models

• The Structure of Estimation Models
• The COCOMO II Model
• The Software Equation

Estimation for Object-Oriented Projects

SOFTWARE PROJECT MANAGEMENT 3

• Software project management begins with a set of
activities that are collectively called project planning
• Before the project can begin, the software team should
estimate:
• work to be done
• resources required
• time from start to finish
• Afterwards, a project schedule is defined, explaining:
• software engineering tasks
• milestones
• responsibility (who is responsible for each task)
• Inter-task dependencies

SOFTWARE PROJECT MANAGEMENT 4

OBSERVATIONS ON ESTIMATION

SOFTWARE PROJECT MANAGEMENT 5

• Planning requires you to make an initial commitment,
even though it’s likely that this commitment will be
proven wrong
• Whenever estimates are made, you look into the future
and accept some degree of uncertainty as a matter of
course
• Useful techniques for time and effort estimation do exist:
• Process and project metrics
• Past experience

SOFTWARE PROJECT MANAGEMENT 6

FACTORS AFFECTING ESTIMATION
1. Project complexity: though complexity is a relative
measure & varies for each scenario
2. Project size: as size increases, interdependency
increases & problem decomposition becomes difficult
3. Degree of structural uncertainty (of requirements):
unclear requirements cause problems
4. Availability of historical information: past experiences
count

Modern software approaches (evolutionary & agile)

believes in iterative methodologies; revision is not a major
concern

SOFTWARE PROJECT MANAGEMENT 7

THE PROJECT PLANNING PROCESS

SOFTWARE PROJECT MANAGEMENT 8

 TASK SET FOR PROJECT PLANNING
1. Establish project scope. 5. Estimate cost and effort.
2. Determine feasibility. 1. Decompose the problem.
2. Develop two or more estimates
3. Analyze risks using size, function points,
4. Define required resources. process tasks, or use cases.
1. Determine required human 3. Merge the estimates.
resources. 6. Develop a project schedule
2. Define reusable software 1. Establish a meaningful task set.
resources. 2. Define a task network (WBS).
3. Identify environmental 3. Use scheduling tools to develop
resources. a time-line chart.
4. Define schedule tracking
mechanisms.

SOFTWARE PROJECT MANAGEMENT 9

SOFTWARE SCOPE AND FEASIBILITY

SOFTWARE PROJECT MANAGEMENT 10

• Software scope describes:
• functions and features that are to be delivered to end
users
• Input and output data elements
• the content that is presented to users as a
consequence of using the software
• non-functional needs, e.g. performance, constraints,
interfaces, and reliability
• 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.

SOFTWARE PROJECT MANAGEMENT 11

• Functions described in the scope are then evaluated
and refined for more details.
• Performance considerations for processing and response
time are covered.
• Constraints are identified for the software by external
hardware, available memory, or other existing systems.
• Once all these things are done, feasibility is checked, on
the basis of:
• Technology
• Finance
• Time
• Resources

SOFTWARE PROJECT MANAGEMENT 12

ASSIGNMENT 1:

SCOPE & VISION STATEMENT

SOFTWARE PROJECT MANAGEMENT 13

RESOURCES

SOFTWARE PROJECT MANAGEMENT 14

• 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
• statement of availability
• time when the resource will be required
• duration of time that the resource will be applied
• The last two characteristics can be viewed as a time
window

• Organization resources vs. Project resources

SOFTWARE PROJECT MANAGEMENT 15

HUMAN RESOURCES
1. Skills
 evaluate software scope and select the skills
required (technical & organizational) to complete
development
 For small projects, a single individual may play
multiple roles
2. Number
 Estimate development effort first and then decide
number of resources required
3. Location
 Larger projects maybe dispersed across different
locations

SOFTWARE PROJECT MANAGEMENT 16

REUSABLE SOFTWARE RESOURCES
Component-based software engineering emphasizes
reusability
• Off-the-shelf components: Validated existing software
that can be acquired from a past project or a third party
(COTS-commercial off-the-shelf)
• Full-experience components: Existing specifications,
designs, code, or test data developed for similar past
projects; current team members have full experience in
the application area represented so, modifications
involve low risk

SOFTWARE PROJECT MANAGEMENT 17

REUSABLE SOFTWARE RESOURCES
• Partial-experience components: Existing specifications,
designs, code, or test data developed for related past
projects but will require considerable modifications;
current team members have only limited experience in
the application area so, modifications have a fair degree
of risk.
• New components: Software components must be built by
the software team specifically for the needs of the
current project.

SOFTWARE PROJECT MANAGEMENT 18

ENVIRONMENTAL RESOURCES
• The software engineering environment that supports a
software project, incorporates hardware and software
• Hardware provides a platform that supports the tools
(software) required to produce the work products
• Network resources are also needed for connectivity

SOFTWARE PROJECT MANAGEMENT 19

WORK BREAKDOWN STRUCTURE

SOFTWARE PROJECT MANAGEMENT 20

• A list of tasks that will generate all of the work products
• A work breakdown structure element may be a product,
or task or a combination

SOFTWARE PROJECT MANAGEMENT 21

ASSIGNMENT 2:

WORK BREAKDOWN STRUCTURE

SOFTWARE PROJECT MANAGEMENT 22

SOFTWARE PROJECT ESTIMATION

SOFTWARE PROJECT MANAGEMENT 23

• Too many variables (human, technical, environmental,
political) can affect the ultimate cost of software and
effort applied to develop it – difficult to estimate
• To achieve reliable cost and effort estimates, a number
of options arise:
• Delay estimation until late in the project – not always
possible
• 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.

SOFTWARE PROJECT MANAGEMENT 24

DECOMPOSITION TECHNIQUES

SOFTWARE PROJECT MANAGEMENT 25

SOFTWARE SIZING
The accuracy of a software project estimate is dependent
on a number of things:
1. the degree to which you have properly estimated the
size of the product to be built;
2. the ability to translate the size estimate into human
effort, calendar time, and money;
3. the degree to which the project plan reflects the
abilities of the software team;
4. the stability of product requirements and the
environment that supports the software engineering
effort.

SOFTWARE PROJECT MANAGEMENT 26

SOFTWARE SIZING
• Software size refers to a quantifiable outcome of the
software project
• If a direct approach is taken, size can be measured in
lines of code (LOC).
• If an indirect approach is chosen, size is represented
as function points (FP).

SOFTWARE PROJECT MANAGEMENT 27

PROBLEM-BASED ESTIMATION
• When LOC is used as the estimation variable,
decomposition is absolutely essential and is often taken
to considerable levels of detail. The greater the degree
of partitioning, the more likely reasonably accurate
estimates of LOC can be developed
• For FP estimates, information domain characteristics
(inputs, outputs, data files, inquiries, and external
interfaces) are taken into account
• A three-point or expected value for the estimation
variable (size) S can be computed as
S = (Soptimistic + 4Smost likely + Spessimistic)/6

SOFTWARE PROJECT MANAGEMENT 28

PROCESS-BASED ESTIMATION
• The process is decomposed into a relatively small set of
tasks and the effort required to accomplish each task is
estimated
• Average labor rates (cost per unit effort) are then
applied to the effort estimated for each process activity

SOFTWARE PROJECT MANAGEMENT 29

ESTIMATION WITH USE CASES
Problems with use case estimation:
• Use cases are described using many different formats
and styles—there is no standard form.
• Use cases represent an external view (the user’s view) of
the software and can be written at many different levels
of abstraction.
• Use cases do not address the complexity of the functions
and features that are described.
• Use cases can describe complex behavior (e.g.,
interactions) that involve many functions and features

SOFTWARE PROJECT MANAGEMENT 30

ESTIMATION WITH USE CASES
But a theory suggests that use cases can be used as a basis
for LOC of FP estimation, as per the following formula
LOC estimate = N x LOCavg + [(Sa/Sh – 1) + (Pa/Ph - 1)] x
LOCadjust

N = actual number of use cases

LOCavg = average LOC per use case for similar component
done in past
Sa = actual scenarios per use case
Sh = average scenarios per use case for this type of subsystem
Pa = actual pages per use case
Ph = average pages per use case for this type of subsystem
LOCadjust = n percent of LOCavg; n is defined locally

SOFTWARE PROJECT MANAGEMENT 31

RECONCILING ESTIMATES
• Estimates are gathered from a number of methods and
then an average is computed
• A large variation between average and actual
estimates occurs because or 2 reasons:
• scope of the project is not adequately understood or
has been misinterpreted by the planner
• data used for problem-based estimation techniques is
inappropriate for the application, obsolete, or has
been misapplied

SOFTWARE PROJECT MANAGEMENT 32

EMPIRICAL ESTIMATION MODELS

SOFTWARE PROJECT MANAGEMENT 33

THE STRUCTURE OF ESTIMATION MODELS
• An estimation model uses empirically derived formulas to
predict effort for LOC or FP
• Values for LOC of FP are estimated as before and are
then plugged into the models
• A general form of the model is:
E = A + B x (ev)^C
A, B, C = empirically derived constants
E = effort in person-months
ev = estimation variable (LOC or FP)

SOFTWARE PROJECT MANAGEMENT 34

COCOMO II MODEL (COnstructive COst MOdel)

COCOMO II is a hierarchy of estimation models that

address the following areas:
• Application composition model: Used during the early
stages of software engineering e.g. prototyping of user
interfaces, consideration of software and system
interaction, assessment of performance etc.
• 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.

SOFTWARE PROJECT MANAGEMENT 35

COCOMO II MODEL (COnstructive COst MOdel)

COCOMO II models require sizing information based on:

1. Function points
2. Lines of source code
3. Object points: an indirect software measure that is
computed using counts of the number of
1. screens (at the user interface)
2. reports generated by the system
3. components likely to be required to build the
application

SOFTWARE PROJECT MANAGEMENT 36

COCOMO II MODEL (COnstructive COst MOdel)

• Each object instance (screen/report) is classified into one

of three complexity levels (simple, medium,difficult)
• Complexity is a function of the number and source of the
client and server data tables that are required to
generate the screen or report and the number of views or
sections presented as part of the screen or report

SOFTWARE PROJECT MANAGEMENT 37

COCOMO II MODEL (COnstructive COst MOdel)

1. Assess object counts: estimate the number of screens,

reports and 3GL components needed in the app
2. Determine complexity for each based on

SOFTWARE PROJECT MANAGEMENT 38

COCOMO II MODEL (COnstructive COst MOdel)

3. Find the weight against each complexity

4. Add all the weights and determine the object point

count

SOFTWARE PROJECT MANAGEMENT 39

COCOMO II MODEL (COnstructive COst MOdel)
5. If component-based development or reuse is applied,
the percent of reuse (%reuse) is estimated and the
object point count is adjusted:
NOP = (object points) x [(100 - %reuse)/100]
6. Based on this, we derive a productivity rate:

7. Effort is estimated:
Estimated Effort = NOP/PROD

SOFTWARE PROJECT MANAGEMENT 40

THE SOFTWARE EQUATION
Software equation assumes a specific distribution of effort
over the life of a software development project
E = (LOC x B^0.333/ P^3) x 1/t^4
E = effort in person-months or person-years
t = project duration in months or years
B = special skills factor that increases the need for
integration, testing, quality assurance, documentation,
and management skills grows
P = productivity parameter that reflects: overall process
maturity and management practices, the extent to
which good software engineering practices are used,
the level of programming languages used, the state of
the software environment, the skills and experience of
the software team, and the complexity of the
application

SOFTWARE PROJECT MANAGEMENT 41

THE SOFTWARE EQUATION
Special Skill Factor
B = 0.16 for small programs of KLOC = 5 to 15
B = 0.39 for programs greater than 70 KLOC

Productivity parameter
P = 2000 for development of real-time embedded software
P = 10,000 for telecommunication and systems software
P = 28,000 for business systems applications

SOFTWARE PROJECT MANAGEMENT 42

THE SOFTWARE EQUATION
Two equations are further derived using the software
equation:
1. tmin = 8.14 (LOC/P^0.43) in months for t >6 months

2. E = 180 x B x t^3 in person-months

for E ≥ 20 person months & t in years

SOFTWARE PROJECT MANAGEMENT 43

ESTIMATION FOR OBJECT-ORIENTED
PROJECTS

SOFTWARE PROJECT MANAGEMENT 44

1. Develop estimates using effort decomposition, FP
analysis, or any other method
2. Develop use cases and determine a count
3. Determine the number of key classes
4. Categorize the type of interface and develop a
multiplier; multiply the number of key classes by the
multiplier to obtain an estimate for the number of
support classes

5. Multiply the total number of classes (key + support) by

the average number of work units per class (15-20
person-days per class)
6. Cross-check the class-based estimate by multiplying
the average number of work units per use case
SOFTWARE PROJECT MANAGEMENT 45