SOFTWARE ENGINEERING TECHNIQUES

LESSON 12:

Topics Covered The Rayleigh function describes the relationship of the

Putnam Estimation Resource Model, Risk Management manpower curve to time and has a parameter ‘a’ (the shape
parameter) which determines how sharp the curve is. Delivery
Objectives
corresponds to the peak of the curve. For a delivery time td , the
Upon completion of this Lesson, you should be able to:
shape parameter is given as
• Know how estimation is done using the Putnam estimation
a = 1/(2 * td2)
model
A factor of interest in understanding how projects behave was
• Know what is risk management
the ratio D given by
We have seen in our previous lecture the procedure for
D = K/td2
estimation using the COCOMO model. Now let us see how is
it done using Putnam Estimation Model. D is the slope of the manpower distribution at the start time (t
= 0).
Putnam Estimation Model
The Putnam estimation model is a dynamic multivariate model Putnam plotted the data from 100 projects using the log
for effort estimation. Lawrence Putnam developed the model in function and found that projects reputed to be easy to be
1977 using data collected from the software projects of the US grouped around a smaller value of D and systems reputed to
Army Computer Systems Command. The Putnam model has be difficult to develop had a larger value of D. D is therefore
been derived from labour distributions of large projects (over called difficulty. The difficulty D shows that a project is more
30 person years). Putnam has further worked on the initial difficult to develop when the manpower demand is high or the
model and refined the approach, describing it further in his later time (td ) is short.
works. Again in this model the relationship between size and D can also be expressed in terms of the peak manning m o as
effort is non-linear. D = K/ td2 = m0 e1/2/ td
The Putnam model is also highly sensitive to delivery time or, to get the peak manpower,
(more than COCOMO). According to the Putnam model,
m0 = K/ td(e1/2)
relatively small extensions in the delivery schedule can result in
substantial savings of effort. Where, e is the base of the natural logarithm (el/2 is 1.648721).
Another important relationship of concern was how fast can
manpower (number of team members) be built up in a project,
and when does such building up become counter-productive.
Putnam’s analysis of the data should him that when the project
scale increased, so did the development time, and that this
increase was such that the ratio K/td 3 (called the manpower
buildup parameter) remained constant about one of the three
values-8, 15 or 27. Terming this constant value as Do , Putnam
found:
• Do = 8, corresponded to new software with many interfaces
and interactions with other systems.
• Do = 15, corresponded to a new stand-alone system.
Putnam, in his study of data from many projects, found that
• Do = 27, corresponded to software rebuilt from existing
the manpower curve of software projects could be modeled by
software.
the Norden-Rayleigh curve. A study of software projects
revealed that software projects followed the Rayleigh manpower He also found that Do varied slightly from organization to
distribution, superimposed with “noise” corresponding to the organization. Essentially, the smaller the value of Do , the longer
perennial problem of imprecise and changing requirements. the development calendar time. The higher the value of Do , the
steeper the profile and shorter the time for the project.
Putnam further used the data to understand the underlying
relationships between the various factors. He used the data to While estimating for a project, an appropriate Do can be
identify factors that model and explain the behavior of software assumed to further decide on the development time.
projects and give management enough information to make One important relationship found by Putnam was the
decisions and try trade-offs. The Putnam model incorporates relationship of software size to other factors. Putnam used
concepts like manpower buildup, technology, environment and available data to arrive at an empirical relationship between
process productivity.

© Copy Right: Rai University

3E.253 43
 productivity and difficulty. He found that productivity could be parameters to create a “productivity index” instead. The
SOFTWARE ENGINEERING TECHNIQUES

expressed as productivity index ranges from 1 to 34. For example, Putnam

Productivity = constant * difficulty -2/3 states that the application category “business” has a mean
productivity index of 16.2. Productivity index of 16 is
He further used this to arrive at the relationship between size,
equivalent to productivity parameter of 28,657. Productivity
effort, development time and difficulty. He expressed it as what
index of 17 is equivalent of productivity parameter of 35,422.
is called the Software Equation. The Putnam software equation
is of the form While the actual computation needs the productivity factor, the
users of the model need to refer only to the productivity index.
L = Ck K 1/3 td4/3
The minimum time to do a project is,
where,
Td-min = 0.68 (SLOC/pp) 0.43 years
K is the effort in years,
with the corresponding expected effort being,
L is the size, in delivered source lines of code (SLOC),
E = 15B t3d-rnin
Ck is a constant which is a function of local conditions and
depends on the state of-the-art (called the technology factor or To use the software equation for estimating, the steps are:
the environment factor), and td is the development calendar • Using past data, calibrate the productivity parameter,
time in years. manpower buildup parameter.
The Putnam software equation shows the sensitivity of the • Estimate the project size of the project to be estimated in
effort to the calendar time given a size. SLOC (convert any functional size measures into SLOC).
The technology factor indicates the productivity of the software • Use the software equation and the manpower buildup
producing process of the organization. equation to calculate effort and calendar time.
The development effort (DE) is the integration of this up to t Estimation using the Putnam model can also be done using
= td (the peak of the curve) and is found to be, the Monte Carlo simulation. It can also be set up as a linear
DE = O.39K programming problem with constraints like maximum
manpower buildup, maximum peak manpower, minimum
Looking further at the software equation, it can be re-written as
peak manpower, contract delivery time and budgeted money for
L / Ck = K 1/3 td 4/3
development.
Since the size L and the technology factor Ck are constant, the
Putnam along with Myers has also done some research on the
left-hand side is a constant for a system. This shows that the
quality aspect of software in relation to estimation. The
relationship between effort and delivery time is highly non-
important aspect of this research is their discussion on defect
linear. Even a small extension in the project time can result in
drivers-drivers that tend to increase the defects:
substantial savings in the effort. A 10% reduction of the project
duration increases the difficulty by about 60%! • Number of persons: The relationship of defects to this is
non-linear since as the number of persons working on a
An alternate way of expressing the software equation is,
project rises, the quality of interactions suffers and causes
Product = Productivity Parameter * (Effort / B)1/3 * more defects. Peaking a project sooner (faster manpower
(Time)4/3 build up) to cope with compressed schedules therefore
Or, the productivity parameter (PP) is, increases defects.
PP = SLOC/[(E/B)1/3td4/3] • Time pressure: With an increase in time pressure, people
Where, tend to make more errors. Compressing a schedule therefore
has quality implications.
E is the effort (in man years),
• Size of the product: The larger the size of the system the
B is a special skills factor and is based on size, and
number of defects is disproportionately higher.
td is the development time in years.
Risk Analysis
The factor B increases slowly with size and is tabulated for the Before we can get started with the software project
size in SLOC. development, we must answer some questions concerning risk.
It is 0.39 for projects e” 70 KSLOC and as low as 0.16 for When risk is considered in the context of soft engineering, three
projects 5-15 KSLOC. The calibration is done using data of conceptual problems are always evident:
past projects. • The future is our concern-what risks might cause the
Putnam points out that the productivity parameter can vary software project to go wrong?
widely depending on the technology and the environment. • Change is our concern-how will changes in customer
Even for the same type of technology and within the same requirements, development technologies, target computers,
environment, this parameter can change over time due to and all other entities connected to the project affect timeliness
learning and process maturity. Putnam has computed the range and overall success?
of the pr<1ductivity parameter between 754 and 2178309 in his
book Controlling Software Development. To make things
simpler for users, he has created ranges of productivity

© Copy Right: Rai University

44 3E.253
• Decisions are our concern-what methods and tools should Risk Projection

SOFTWARE ENGINEERING TECHNIQUES

we use, how many people should be involved, how much Risk projection, also called risk estimation, attempts to rate each
emphasis on software quality is sufficient? risk in two ways-the likelihood that the risk real, and the
Risk analysis is actually four distinct activities: consequence of the problems associated with the risk. The
software project planner along with others-managers and
• Risk Identification
technical staff, performs four risk projection activities:
• Risk Projection
1. Establish a scale that reflects the perceived likelihood of a
• Risk Assessment risk,
• Risk Management 2. Delineate the consequences of the risk,
Risk Identification 3. Estimate the impact of the risk on the project and the
It is important to identify all the risks that are obvious to both software product, and
managers and software engineers. It is possible to categorize 4. Indicate the overall accuracy of the risk projection.
risks in many different ways:
Risk Assessment
• Project risks-budgetary, schedule, staffing, resources,
At this point in the risk analysis process, we establish with each
customer requirements.
risk a set of triplets of the form:
• Technical risks-software design, verification, interfacing,
[ r i, l i , x i ]
implementation, and maintenance.
where rI is risk, lI is the likelihood (probability) of the risk, and
• Business risks-market risk, management risk, budget risk,
xI is the impact of the risk. For assessment to be useful, a risk
and obsolescence risk.
referent level must be defined. For software projects, cost,
Risk identification lists the specific project risks within the broad schedule, and performance represent three typical risk referent
categories outlined above. levels. That is, there is a level for cost overrun, schedule slippage,
Following are several typical risk categories and risk items that or performance degradation that will cause the project to be
may threaten your project [McConnell, 1996]. If any of these terminated.
things have happened to you, put them on your master risk During risk assessment the following steps are performed:
factor checklist to remind each of your future project managers
1. Define the risk referent levels
to ask themselves if it could happen to them. There are no
magic solutions to any of these risk factors, so we need to rely 2. Attempt to develop a relationship between each [ ri , li , xi ]
on past experience and a strong knowledge of contemporary and each of the referent levels
software engineering and management practices to control those 3. Predict the set of referent points that define a region of
risks we are most concerned about. termination (bounded by a curve or areas of uncertainty
Capers Jones has identified the top five risk factors that threaten 4. Try to predict how compound combination of risks will
projects in different application sectors [Jones, 1994]. Table 1 affect a referent level.
illustrates those factors, and the approximate percent of projects Risk Management
to which they apply, in the management information systems The triplet [ ri , li , xi ] (risk description, likelihood, and impact)
(MIS) and commercial software sectors. associated with each risk is used as the basis from which risk
Table 1. Most Common Risk Factors for Various Project management steps are developed. For example, assume that
Types high staff turnover is noted as a project risk, r1. Based on past
Project Risk Factor Percent history, the likelihood, l1, of high turnover is estimated to be
0.70 (70 percent, high), and the impact, x1, is projected to
Sector increase project duration by 15 percent and overall cost by 12
of
percent. Given these data, necessary risk management steps are
Projects proposed:
• Define documentation standards and ensure documents are
at Risk
developed in a timely manner
MIS Creeping user requirements 80% • Schedule reviews of all work
Excessive schedule pressure 65%
• Define a backup staff member for every critical staff.
Low quality 60%

Cost overruns 55%

Inadequate configuration control 50%
Commercial Inadequate user documentation 70%
Low user satisfaction 55%
Excessive time to market 50%
Harmful competitive actions 45%
Litigation expense

© Copy Right: Rai University

3E.253 45
 Boehm, Barry W. and Papaccio, Philip N.
SOFTWARE ENGINEERING TECHNIQUES

“Understanding and Controlling Software

Costs.”
Cuelenaere, A. M. E., van Genuchten, M.
J. I. M. and Heemstra, F. J. “Calibrating a
Software Cost Estimation Model: Why
and How” in Information and Software
Technology, v. 29, Dec. 1987, pp. 558-567.
Dreger, J. Brian. Function Point Analysis.
Englewood Cliffs, NJ: Prentice Hall, 1989.
Banker, R., Kauffman, W., and R. Kumar.
“An Empirical Test of Object-Based
Output Measurement Metrics in a
Computer Aided Software Engineering
(CASE) Environment.” Unpublished
manuscript.
Kemerer, Chris F. “An Empirical
Validation of Software Cost Estimation
Models.” Communications of the ACM,
Summary 30: 416-429.
Cost estimation is the activity where the overall cost requirement Mendelson, Haim. The Economics of Information Systems
for the project and the breakup of the cost for different phases Management. Unpublished manuscript, 1989.
is estimated. As human resources are the most important for
Miyazaki, Y., Takanou, A., and Nozaki, H. “Method to estimate
software development, cost estimates are often given in terms
parametere values in software prediction models” in
of persin-months(PM). In COCOMO, the overall schedule is
Information and Software Technology, v. 33, April 1991, pp.
obtained in a similar way as the overall cost. The Putnam
239-243.
model is also highly sensitive to delivery time (more than
COCOMO). According to the Putnam model, relatively small Symons, Charles R. “Function Point Analysis.”
extensions in the delivery schedule can result in substantial Those who are interested in further books and depending on
savings of effort. Putnam, in his study of data from many the availability you can further browse through these following
projects, found that the manpower curve of software projects books also if you find time.
could be modeled by the Norden-Rayleigh curve. A study of • An overview of COSMIC-FFP field trial results by Abran,
software projects revealed that software projects followed the A., Symons, C., Oligny, S.
Rayleigh manpower distribution, superimposed with “noise”
• Applicability of FFP at Siemens AT by Dumke, R.R., Foltin,
corresponding to the perennial problem of imprecise and
E.,Weber, S., Schweikl, U.
changing requirements.
• Applying Full Function Points To Drive Strategic Business
Putnam further used the data to understand the underlying
Improvement Within the Real-Time Software Environment
relationships between the various factors. He used the data to
by Fred Bootsma
identify factors that model and explain the behavior of software
projects and give management enough information to make • Applying SPC to the Personal Software Process by Mark C.
decisions and try trade-offs. Paulk
The last topic that is covered is risk management. This is a • Cost Estimating For IT Projects by Management Concepts
relatively new area that is gaining importance due to the • Cost Models for Future Software Life Cycle Processes by
increasing application of computer systems in increasingly Barry Boehm, Bradford Clark, Ellis Horowitz, Chris
complex environments. Risk is the possibility of loss due to Westland
inability of the project to meet the goals. Risk management • COTS in the Real World: A Case Study in Risk Discovery and
requires that risks be identified, analyzed, and prioritized. Based Repair by Scott Hissam, Daniel Plakosh
on the priorities, plans can be devised to minimize the risks.
• Counting Function Point from Uses Cases by Not
Further Readings and Information Sources mentioned
Albrecht, A. J. “Measuring Application Development • Establishing a Software Measurement Process by Donald R.
Productivity. In Proceedings of the IBM Applications McAndrews
Development Symposium. GUIDE/SHARE (Monterey, CA,
• Estimating Software Earlier and More Accurately by David
Oct. 14-17). IBM. 1979, pp. 83-92.
Herron, David Garmus
Bailey, John W. and Basili, Victor R. “A Meta-Model for
• Estimation Model by Sudhir H Thakre
Software Development Resource Expenditures.”
• Function Points Step by Step by David Longstreet

© Copy Right: Rai University

46 3E.253
• High Quality, Low Cost Software Inspections by Louis A. Notes

SOFTWARE ENGINEERING TECHNIQUES

Poulin
• Large Limits to Software Estimation by J. P. Lewis
• Large Limits to Software Estimation by J. P. Lewis, Disney
TSL
• Modern Empirical Cost and Schedule Estimation Tools by
Thomas McGibbon
• Multidimensional Software Performance Measurement
Models: A Tetrahedron-based Design by Luigi Buglione &
Alain Abran
• Safe and Simple Software Cost Analysis by Barry Boehm
• Saving for a Rainy Day by Karl Wiegers
• Sizing Software with Testable Requirements by Peter B.
Wilson
• Software Cost Estimation Research: Where Next? (extended)
by G.A. Bell , M.A. Cooper and J.O. Jenkins
• Software Development Cost Estimation Approaches - A
Survey by Barry Boehm and Chris Abts, and Sunita Chulani
• Software Effort and Schedule Estimation : A Case Study by
Mahil Carr,Department of Information Systems, City
University of Hong Kong,83 Tat Chee Avenue,Hong Kong
• Software Measurement for DoD Systems:
Recommendations for Initial Core Measures by Anita D.
Carleton, Robert E. Park,Wolfhart B. Goethert,William A.
Florac,Elizabeth K. Bailey
• Software Project Estimation by Kathleen Peters
• Software Project Estimation by Carol Dekkers and Barbara
Emmons
• Software Size Measurement: A Framework for Counting
Source Statements by Robert E. Park
• The COCOMO 2.0 Software Cost Estimation Model by
Barry Boehm, Bradford Clark, Ellis Horowitz, Ray Madachy,
Richard Shelby, Chris Westland
• The Estimation of Effort Based on Use Cases by John
Smith,Rational Software
• The Real Costs of COTS by Arlene F. Minkiewicz , PRICE
Systems, L.L.C.
• The Role of Function Points in Software Development
Contracts by Paul Radford and Robyn Lawrie
• True Estimates Reduce Project Risk by Mark R.
Durrenberger, PMP
• Trustworthiness of Software Value Points by Don O’Neill
• UKHEC Report on Software Estimation by K.
Kavoussanakis, Terry Sloan
• Using Function Points: Are FPs more useful than a Swiss
Army knife? by David Longstret
• Using Functional Sizing in Software Estimating by
CHARISMATEK
Web Resources
http://sunset.usc.edu/research/putnam/index.html

© Copy Right: Rai University

3E.253 47