Select a publication to download, then click the
selected title.
"Software Estimating Models: Three Viewpoints," CrossTalk, Hill AFB, Ogden
STSC, February 2006
Abstract:
This article compares the approaches taken by three widely used models for
software cost and schedule estimation. Each
of the models is compared to a common framework of first-, second-, and
third-order models to maintain consistency in the comparisons.
The comparisons illustrate significant differences between the models,
and show significant differences in the approaches used by each of the model
classes.
"Software Sizing
Definitions, " USAF/STSC, NASA, NRO, Tecolote Associates, September
2005
Abstract: The
problem of “what is a source line of code” has been a lingering issue ever
since the beginning of software development. In spite of definitions
published be experts as early as 1980, the misuse has continued unabated.
In September 2005 members of the USAF, NRO, NASA, and Tecolote held a working
session that cast a definition of a SLOC that is consistent with the major
estimating tools and code counters coming into prominence today.
"Data Collection Instruction Manual
", Software Technology Support Center, Hill AFB, UT,
September 2005
Abstract:
Historical software development data from
the various phases of the development process is crucial to government cost
analysts in predicting and validating size, cost, and schedule for existing and
system software development projects. The
software development database is a repository for data collected during the
software development process for systems.
The database contains key information for
each individual software component or Computer Software Configuration Item (CSCI)
within a single project. Data is
collected at various maturity levels during the development process.
Ideally, data would be collected at each of the major points starting
with the concept phase through the requirements and design reviews and up to the
final qualification testing. In
reality, much of this data is unavailable for many of the completed
system development projects, so the database contains the data that is
obtainable. Yet, the database is an
ongoing effort and will continue to be populated with new data.
The fundamental principle behind the database input effort is validation
of all data prior to it becoming part of the database.
This process involves establishing a common set of references for the
possible estimating models, determining the development environment, and
carefully examining and analyzing the data to insure it is factual and
realistic. The validation process is
the differentiating element of the database that sets it apart from any past
database efforts.
The data collected for each CSCI describes
the basic information such as product sizing (new, modified, and reused code),
the development effort and maturity, and the development environment (language,
experience, etc.). The data fields
allow easy input regardless of what model was used to create the original data.
These models include the PRICE STM
model, the Galorath Incorporated SEER-SEMTM model, the COnstructive
COst MOdel (COCOMO) developed by Dr. Barry Boehm, and the Software Engineering
Inc. SageTM model developed by Dr. Randall Jensen (Dr. Jensen is
presently part of the STSC), and the SLIM model developed by Larry Putnam of QSM.
"Extreme Software Cost Estimating
" CrossTalk, Hill AFB, Ogden STSC, January 2004
Abstract: One
dominating complaint arising from the continuing “software crisis” is the
inability to estimate with acceptable accuracy the cost, resources, and schedule
required for a software development.
Several
methods of schedule and cost estimation have been proposed over the last 25
years with mixed results and partial success due, in part, to the focus and
capability limitations of traditional estimation models.
A significant part of the estimation failures can be attributed to a lack
of understanding of the inner workings of the software development process and
the impact of that process on the parameters used in schedule and cost
estimates. One poorly understood
variable is the impact of management on the development process.
Poor management can increase software cost, schedule and quality more
rapidly than any other aspect of the development process.
On the other hand, good project management can decrease development cost
and schedule more rapidly than any other factor.
The assumption that the software development enjoys good management by
both developer and customer (1) allows the impact of management to be ignored in
estimates, and (2) is simply wrong.
This
presentation describes a management-centric approach to the prediction of
software development cost and schedule in a modern, or extreme, development
environment as opposed to the traditional technology-based approaches.
The presentation introduces techniques necessary to produce realistic,
reliable software development estimates, as well as introducing software
managers to quantitative methods for predicting the impacts of their management
decisions.
“Extreme Software Cost Estimating” was
awarded the Outstanding Software Paper at the International Society of
Parametric Analysts (ISPA) 2003 Annual Conference in
Orlando
,
Florida
.
"Lessons Learned From Another Failed Software Project,
", CrossTalk, Hill AFB, Ogden STSC, September 2003
Abstract: Software
project failure has been with us for a long time.
Volumes have been written about the list of potential problem areas in
the acquisition of large, complex software systems.
The list includes simple things like the cost of reuse, the acquisition
process, unrealistic expectations, and the development environment.
The list hasn’t changed much in the last thirty years.
Unrealistic cost and schedule estimates are causes for project failure as
often as inadequate technology.
Source selection is a critical acquisition
process step. Proper preparation and
diligence in this step is key to a successful software project.
There are several activities essential to successful project planning and
acquisition including risk assessment. This
lessons-learned discussion is based upon a post-mortem analysis of an avionics
software development. The intriguing
analysis results show this project was neither unique nor abnormal.
The problems that surfaced during the project’s inception and following
downhill plunge were common in the mid 1980s environment and are still common
today.
The purpose of this discussion is to
highlight the major software development and management issues that led to this
project’s failure. The issues
presented here are timeless; that is, they are as likely to arise today as they
were at any time in the past.
"A Pair Programming Experience,
" CrossTalk, Hill AFB, Ogden STSC, March 2003
Abstract: Agile methods and extreme programming have risen to the
forefront of software management and development interest over the last few
years. The “Agile Manifesto”
published in Software Development in 2001 created a new wave of interest in the
agile philosophy and re-emphasized the importance of people.
One of the points highlighted in the Manifesto is “We value individuals
and interactions over processes and tools.”
That does not mean processes and tools are evil.
It implies the individuals and interactions (people) are of higher priority than processes and tools.
“Extreme programming” is one member covered by the umbrella of agile
methods. “Pair programming” is a major practice of extreme programming.
The official definition of pair programming is two
programmers working together, side by side, at one computer collaborating on the
same, analysis, design, implementation and test.
In other words -- two programmers, one pencil.
I was introduced to teamwork and pair programming
indirectly as an undergraduate electrical engineering student in the 1950s.
The team concept we used to survive in engineering school were very
effective and became ingrained in my thinking, as well as in my programming and
management research activities. Years
later (1975), I was asked to find ways to improve programmer productivity in a
large software organization. The
undergraduate experience led me to propose an experiment in the application of
what we called “two-person
programming teams.” With the
advent of extreme programming the term became pair programming.
The very positive results of the 1975 experiment are the subject of this
case study.
"An
Economic Analysis of Software Reuse" International Society of
Parametric Analysts Conference 2002, San Diego, CA, May 21-24, 2002
Abstract:
Current software projects tend to maximize reusable component use and minimize
development product size. There are significant advantages to the use of
reusable components including lower development time and effort through the use
of existing, supported components, and reduced risk from proven field tested
components.
The
downside to reusable software comes with high development costs, and from the
significant cost of integrating reusable components into software
products. These integration costs can be devastating if components are
inadequate, poorly defined and documented, or not quite compatible with the
application.
This
paper presents a simplified economic analysis of the cost of software
reuse. The reuse definition used here includes both COTS and existing
software from an upgraded platform. The results are independent of
software estimating tool or model. The model used in this analysis relates
the cost of software development to the reused software level and the costs of
developing and maintaining the software components. COTS software is a
special case of reuse described in the paper.
"On
Calibrating Software Estimation Tools" CrossTalk, Hill AFB, Ogden
STSC,
July 2001
Abstract:
The last decade has brought increasing pressure on software model developers to
include a calibration capability in their models that will reduce errors and
improve software development estimates. An invalid underlying assumption
is that software estimate errors are primarily due to weaknesses in the
estimating technology (models). The intent of this paper is to raise
awareness of software estimate error sources (data and estimator capability),
and to objectively consider the real impacts of model calibration.
"Managing (the Size of) Your Software Projects:
A Project Management Look at Function Points," CrossTalk, Hill AFB, Ogden
STSC, February 1999
Abstract:
This article is an introduction, as well as a refresher, to readers who need
to update their knowledge about function points (FPs).
Function points are a widely used alternate to source lines of code (SLOC)
as a measure of system size. FPs are
a pure measure of the total size of the development system.
"Estimating the Cost of Software Reuse,"
CrossTalk, Hill AFB, Ogden STSC, May 1997
Abstract: Integration costs for reusable software
components are significant, but predictable. This article discusses the major
reuse cost impacts and describes a rational method for projecting cost and
schedule for software developments that incorporate reusable and COTS software
components.
"Management Impact on Software Cost and
Schedule," CrossTalk, Hill AFB, Ogden STSC, July 1996
Abstract:
By focusing on the people-management
facet of software development, appreciable gains in quality and productivity can
result. This article discusses how to enhance communication effectiveness
through motivation, the physical environment and team approaches.
"A New Perspective in Software
Schedule and Cost Estimation," Software Technology Conference 1996, Hill AFB,
Ogden STSC, 21-26 April 1996
Abstract: Cost and Schedule Estimation methods and
tools have focused on the technology aspects of software development since their
inception in the early 1970s. Software estimation researchers have been aware of
other significant impacts on cost and schedule since the mid 1970s. Traditional
technology based software cost drivers are now being re-evaluated from a
management perspective. Additional indicators need be added to account for
management quality and its impact on the development environment. This paper
explores the productivity and quality impact of software management approaches.
Case studies include teaming approaches and management style changes that have produced, at
no additional development cost, productivity gains greater than 150 percent and
error rate reductions of 2 to 3 orders of magnitude. Sage is used to
quantitatively demonstrate the cost and schedule impacts of management quality
and philosophy.
