Lecture5

Software Project Management
Lecture # 5

Outline
 Chapter 23 – “Estimation”
 Introduction
 What is Estimation
 Estimation and Risk
 Project Planning Activities
 Software Scope and Feasibility
 Resources
 Software Project Estimation
 Decomposition Techniques
 Empirical Estimation Models

Introduction
 Software Project Management begins with
'Project Planning’ activities
 Software project planning includes five
major activities:
 Estimation (of work, resources, time)
 Scheduling
 Risk Analysis
 Quality Management Planning
 Change Management Planning

What is Estimation?
 Estimation is to determine how much…
 Money/cost,
 efforts,
 resources and
 time
…will be taken to build a specific software
based system or product.
 Estimation is foundation for all project
planning activities

Estimation Steps – Summary
 Description of product scope
 Decomposition of problem into set of
smaller problems
 Each sub problem is estimated using
historical data, software metrics and
experience (from past projects) as guides.
 Problem complexity and risks are
considered before final estimate is made

Estimation and Risk
 Estimation carries inherent risk & risk leads
to uncertainty
 Estimation risk is measured by the degree of
uncertainty in the quantitative estimates
established for resources, cost, and
schedule.
 Availability of comprehensive historical
information and software metrics (from past
projects) helps establish better estimates
and hence reduces risk factors

Project Planning Process
 Software project planning provides a
framework that enables the manager
to make reasonable estimates
 Although there is inherent uncertainty,
the team embarks on a project plan
 But, this plan must be adapted and
updated as the project progresses

The Software Project Planning
Activities

Software Scope
 It is defined in one of the following ways:
 Narrative description developed after communication with
all stakeholders
 A set of use-cases developed by end-user
 It describes
 functions & features to be delivered to end-user ( these
are evaluated and sometimes refined before estimation is
started)
 “content” presented to users as they use the software
 Performance considerations (processing and response
time, etc)
 Constraints (limits placed on software by external
hardware, available memory, or existing systems)
 Input and output data
 Interfaces and reliability that bound the system

Software Feasibility
 It is conducted after scope identification
 It is very crucial but is often overlooked either
by software engineers or by the impatient
customers and managers
 It addresses questions like
 Can we build software to meet this scope?
 Is the project feasible?

Software Feasibility (Cont.)
 Putnam and Myers address feasibility in four
dimensions
 Technology
 Is the project technically feasible? Is it within state of the art?
Can defects be reduced as needed?
 Finance
 Is it financially feasible? Can the development be completed
at a cost that the software organization, the client or the
market can afford
 Time
 Will the project’s time-to-market beat the competition?
 Resources
 Does the organization have enough resources needed to
succeed?

Resources
 Three categories of resources:
 People/Human resources
 Reusable software components
 Development environment (s/w & h/w tools)
 Each resource has 4 characteristics
 Description of resource
 Statement of availability
 Time when resource will be required
 Duration of time when resource will be applied

1.Human resources
 This estimation involves
 Selecting Skills (required to complete
development)
 Specifying organizational positions (manager,
senior s/w engr, ..) and specialty
 Determining number of people based on
development effort
 For small projects, single person can do all s/w engg
tasks
 For large projects, more number of people involved
which may be geographically distributed. So, location
of resource also specified

2. Reusable Software Resources
 CBSE emphasizes the creation and reuse of software
building blocks (components)
 4 categories of software components
 Off-the-shelf components
 Ready-to-use existing software acquired from third party
(COTS) or from (internal) past projects
 Full-experience components
 Existing specifications, designs, code, test data from past
projects similar to software to be developed (for current
project). May require little modifications
 Partial experience component
 Existing specifications, designs, code, test data from past
projects related to software to be developed (for current
project) but will require substantial modifications
 New components
 Software components that must be built for current project

3. (Development) Environment
resources
 These include hardware and software
support for a software project
 Hardware and software elements availability
and time window must be specified

Software Project Estimation
 Options for cost and effort estimates
 Delay estimation until late in project
 Not a practical approach
 Base estimation on similar past projects
 Reasonable approach but not always successful
 Use simple decomposition techniques to generate
estimates
 Divide and conquer approach. Divide project into major
activities/functions and make estimates
 Use some empirical model for estimation
 Complements decomposition techniques
 Which option is better?
 Each approach can be used as a cross-check for the
other

Decomposition Techniques
 Decomposition can be performed in
two aspects
 Decomposition of problem
 Decomposition of process

1. Software Sizing
 Proper estimation of software size and mapping of
size estimate to human effort, calendar time and cost
are important things which contribute to accuracy of
overall software project estimation
 Direct approach – size is measured as LOC
 Indirect approach – size is measured as function-
points
 Putnam and Myers suggested 4 different approaches
for sizing problem
 Fuzzy logic sizing
 Function point sizing
 Standard component sizing
 Change sizing

Other types of estimations…
2. Problem based estimation
3. FP-based estimation
4. Process-based estimation
5. Use-case based estimation

Empirical Estimation Models
 An estimation model for software uses
empirically derived formulas .
 These formulas can predict effort as a
function of LOC or FP.
 Empirical data (that support most estimation
models) are derived from limited sample of
projects, that is why, no estimation model is
appropriate for all classes of software and in
all development environments.
 Estimation model must be calibrated for
local conditions.

Structure of Estimation Models
 A typical empirical model is derived using
regression analysis on data collected from
past projects
 Overall structure of such models takes the
form
E= A+B x (ev)C
 A, B and C are empirically derived constants, E
is effort in person-months and ev is estimation
variable (either LOC or FP)

Empirical Estimation Models -
Examples
 Proposed LOC-oriented estimation models
 E= 5.2 x (KLOC)0.91
Walston-Felix model
 E= 5.5 + 0.73 x (KLOC)1.16
Bailey-Basili model
 E= 3.2 x (KLOC)1.05
Boehm simple model
 E= 5.288 x (KLOC)1.047
Doty model for KLOC>9
 Proposed FP-oriented estimation models
 E= -91.4 + 0.355 FP Albrecht and Gaffney model
 E= -37 + 0.96 FP Kemerer model
 E= -12.88 + 0.405 FP small project regression model

The COCOMO II Model
 Boehm suggested a hierarchy of software
estimation models named: COCOMO.
 COCOMO stands for COnstructive COst
MOdel
 Original COCOMO model became one of
the most widely used and discussed
software cost estimation models
 COCOMO evolved into COCOMO II

COCOMO II Model (Cont.)
 COCOMO II addresses the following areas:
 Application composition model
 Used during the early stages of s/w engg.
 when UI prototyping, s/w and system interaction, performance
assessment and tech. evaluation are paramount.
 Early design stage model
 Used once requirements have been stabilized and
basic architecture has been established
 Post-architecture stage model
 Used during the construction of software
 Like other estimation models, COCOMO II
uses sizing information (object points, function
points and lines of code).

 COCOMO II Application composition model uses
object points
 Object points is an indirect software measure computed
using
 Screens (at UI)
 Reports
 Components likely to be required to build the application
 Each object instance is classified into one of these
complexity levels (simple, medium, difficult) on criteria
suggested by Boehm.
 Complexity is a function of number of client and server
tables required to generate a screen or report and number
of sections or views within a screen or report
 After determining complexity, no. of screens, reports and
components are weighted as in figure (23.6).
 The object point count is determined by multiplying
original no. of object instances by weighting factor.

Figures 23.6 & 23.7
Object Type Complexity Weight
Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3GL component 10
Developer’s
experience/capabilit
y
Very Low Low Nominal High Very High
Environment
maturity/capability
Very Low Low Nominal High Very high
PROD 4 7 13 25 50

 For component-based development or when
software reuse is applied, the %reuse is estimated
and object point count is adjusted:
 NOP = (object points) x [(100 - %reuse)/100]
 NOP is new object points
 To derive estimate of effort based on computed
NOP value, a productivity rate must be derived
 PROD = NOP / person-month
 Estimate of project effort can be derived as:
 Estimated effort = NOP/PROD

 Excluded
 23.8
 23.9 and sub topics

Lecture5

More Related Content

What's hot (20)

Similar to Lecture5 (20)

Recently uploaded (20)

Lecture5