Scribd
Upload
4K views5 pages

Putnam Model: The Software Equation

Uploaded by

smartkundan143
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
4K views5 pages

Putnam Model: The Software Equation

Uploaded by

smartkundan143
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Putnam model

The Putnam model is an empirical software effort estimation model. As


a group, empirical models work by collecting software project data (for
example, effort and size) and fitting a curve to the data. Future effort
estimates are made by providing size and calculating the associated
effort using the equation which fit the original data (usually with some
error).

Created by Lawrence Putnam, Sr. the Putnam model describes the time
and effort required to finish a software project of specified size. SLIM
(Software Lifecycle Management) is the name given by Putnam to the
proprietary suite of tools his company QSM, Inc. has developed based
on his model. It is one of the earliest of these types of models
developed, and is among the most widely used. Closely related
software parametric models are Constructive Cost Model (COCOMO),
Parametric Review of Information for Costing and Evaluation – Software
(PRICE-S), and Software Evaluation and Estimation of Resources –
Software Estimating Model (SEER-SEM).

The Software Equation

While R&D projects for the Army and later at GE, Putnam noticed
software staffing profiles followed the well-known Rayleigh
distribution.

Putnam used his observations about productivity levels to derive the


software equation:

B1/3 . Size/Productivity – Effort1/3 . Time4/3

Where :
 Size is the product size (whatever size estimate is used by your
organization is appropriate). Putnam uses ESLOC (Effective Source
Lines of Code) throughout his books.
 B is a scaling factor and is a function of the project size.
 Productivity is the Process Productivity, the ability of a particular
software organization to produce software of a given size at a
particular defect rate.
 Effort is the total effort applied to the project in person-years.
 Time is the total schedule of the project in years.

In practical use, when making an estimate for a software task the


software equation is solved for effort:

Effort = [ Size / Productivity . Time4/3]3 .B

An estimated software size at project completion and organizational


process productivity is used. Plotting effort as a function of time yields
the Time-Effort Curve. The points along the curve represent the
estimated total effort to complete the project at some time. One of the
distinguishing features of the Putnam model is that total effort
decreases as the time to complete the project is extended. This is
normally represented in other parametric models with a schedule
relaxation parameter.

This estimating method is fairly sensitive to uncertainty in both size and


process productivity. Putnam advocates obtaining process productivity
by calibration.

Putnam makes a sharp distinction between 'conventional productivity' :


size / effort and process productivity.

One of the key advantages to this model is the simplicity with which it is
calibrated. Most software organizations, regardless of maturity level
can easily collect size, effort and duration (time) for past projects.
Process Productivity, being exponential in nature is typically converted
to a linear productivity index an organization can use to track their own
changes in productivity and apply in future effort estimates.

Recalling the software equation [PUT92].I can demonstrate


the highly nonlinear relationship between chronological time to
complete a project and human effort applied to the project. The
number of delivered lines of code (source statements), L, is related to
effort and development time by the equation:

L = P x E1/3t4/3

where E is development effort in person-months, P is a productivity


parameter that reflects a variety of factors that lead to high-quality
software engineering work (typical values for P range between 2,000
and 12,000), and t is the project duration in calendar
months.Rearranging this software equation, we can arrive at an
expression for development
effort E:

E = L3/( P3t4 ) (7-1)

where E is the effort expended (in person-years) over the entire life
cycle for software development and maintenance and t is the
development time in years. The equation for development effort can be
related to development cost by the inclusion of a burdened labor rate
factor ($/person-year).
This leads to some interesting results. Consider a complex, real-time
software project estimated at 33,000 LOC, 12 person-years of effort. If
eight people are assigned to the project team, the project can be
completed in approximately 1.3 years. If, however, we extend the end-
date to 1.75 years, the highly nonlinear nature of the model described
in Equation (7-1) yields:

E = L3/( P3t4 ) ~ 3.8 person-years.


This implies that, by extending the end-date six months, we can reduce
the number of people from eight to four! The validity of such results is
open to debate, but the implication is clear: Benefit can be gained by
using fewer people over a somewhat longer time span to accomplish
the same objective.

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. Although personal experience can be used,
the planner should also have access to a historical database of
projects8 so that estimates can be compared to actual experience.
Function point sizing The planner develops estimates of the
information domain characteristics.
Standard component sizing Software is composed of a number of
different “standard components” that are generic to a particular
application area.
For example, the standard components for an information system are
subsystems, modules, screens, reports, interactive programs, batch
programs, files, LOC, and object-level instructions. The project planner
estimates the number of occurrences of each standard component and
then uses historical project data to determine the delivered size per
standard component. To illustrate, consider an information systems
application. The planner estimates that 18 reports will be generated.
Historical data indicates that 967 lines of COBOL [PUT92] are required
per report. This enables the planner to estimate that 17,000 LOC will be
required for the reports component. Similar estimates and computation
are made for other standard components, and a combined size value
(adjusted statistically) results.
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. Using an “effort ratio” [PUT92] for each type of change,
the size of the change may be estimated.

Putnam suggested that optimal staff build-up on a project


should follow the Rayleigh curve. Only a small number of engineers are
needed at the beginning of a project to carry out planning and
specification tasks. As the project progresses and more detailed work is
required, the number of engineers reaches a peak. After
implementation and unit testing, the number of project members falls.
The Putnam estimation model works reasonably well for
very large systems,but seriously overestimates the effort on medium
and small systems.

You might also like