Home
| FAQs |
Search
| Contact
Us
Products
|
Services and Support |
Library
News
and Events |
Company
|
|
Home
| FAQs |
Search
| Contact
Us |
         |
|
Technical Papers, Presentations, and Articles (Free upon request.) |
Links to Useful Web Sites |
|
Jump to:
Continuous Software Size
Estimating and Tracking Abstract. Adequately planning a software development project requires knowledge of at least two key values: the time and effort. Ad-hoc planning strategies attempt to estimate these two values straight away as functions of past experience and expert judgment. Structured methods for project planning attempt to calculate these values as functions of estimated product-related and project-related values (parameters). A key parameter present in the vast majority of these methods is software size (also referred to as volume or mass). Assuming that size is dynamic and that planning (including replanning or re-baselining) is a process that should continue throughout the life of the project implies, for structured planning strategies, that size estimation itself should be a continuous process. This paper describes a process for managing the size of software development projects through continuous estimation. The process includes a probabilistic approach to size estimation coupled with tracking and assessment of trends which can serve as an indication of project health. This process has direct applicability to the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM) Level 2 Key Process Areas (KPAs) for Software Project Planning and Software Project Tracking and Oversight. It also serves as a Level 4 Quantitative Process Management tool for measuring the effectiveness of an organization’s size estimating and requirements management processes.
How to Illustrate Probability
in Your Estimates
Illustrating Probability in
Software Cost and Schedule Estimating:
Abstract.
This paper starts with the premise, “The
only thing certain about project performance is uncertainty.”
Years of industry experience and project data tells us that cost and
duration estimating is essential to diligent affordability management
and project management. It also tells us that projects behave according
to certain dynamic properties; that time, money, and system content /
performance are all inexorably linked; that this linkage is influenced
by people, project, and product characteristics; and that, prior to
project completion,
everything is
uncertain. A primary goal of
any estimating process should therefore be to not only yield values for
cost
and
duration; it should also indicate whether or not these values satisfy
their corresponding goals within some corresponding desired probability
of success. This paper describes a new chart (we call it a
Ross chart™)
that shows the confidence limits (probabilities of success) and goals
satisfaction of the two coupled dependent variables in a bivariate
estimating relationship. Using a Cost with Duration Estimating
Relationship (CDER) example (i.e., cost coupled with duration as a
function of content / performance and efficiency), the paper describes a
method for stochastic (probabilistic) treatment of bivariate
relationships. It presents the example using Ross charts to show the
degree of risk associated with a particular estimating solution. In
other words, this paper presents a process for performing
confidence-driven estimating.
Instantiating the r2 Software
Estimating Framework for COCOMO: Abstract. This paper references the basis, assumptions, and derivations of the r2 Software Estimating Framework (r2SEF) and then shows this framework instantiated for the COnstructive COst MOdel (COCOMO). The r2SEF is a set of general software effort, duration, and defects estimating relationships that are based on the notion that that projects behave according to certain dynamic properties, that duration, effort, cost, and defects are all inexorably linked (correlated), that these correlations can be expressed as functions of people, project, and product attributes, and that, prior to project completion, everything is uncertain. It is the author’s contention that a primary goal of any thorough project estimating process should be to not only yield estimated values for these metrics; it should also indicate whether or not these estimated values satisfy their corresponding project goals within some corresponding specified confidence limits (probabilities of success). Instantiating the r2SEF for COCOMO extends COCOMO’s capabilities to include defect estimation, to permit schedule versus effort versus cost versus defects tradeoffs within associated limits, and to provide confidence-driven estimating based on people, project, and product uncertainties.
Next Generation Software
Estimating Framework: Abstract. It’s about time we in the software development community revisit the assumptions, relationships, and flexibility contained in our currently-available software estimating models. Most of the current models still implement fundamental relationships that are based on at least 25 years old data and assumptions. In the meantime, data from many thousands of projects have since been collected and offer an opportunity to revisit old assumptions and relationships. This paper documents the basis, assumptions, and derivations behind a set of general software effort, duration, and defects estimating relationships that are based on the notion that software construction is the cumulative effect of people doing work (effort) over some duration (period of elapsed calendar time) that produces a desired software product (size) and unwanted byproducts (defects). This set of relationships is derived from several evidently-good correlations, the prima-ry three being: 1) effort generally increases with increasing size, 2) duration generally increases with increasing effort, and 3) effort generally increases with increasing defects. This derivation ultimately yields three limited tradeoff relationships: one between effort and duration, one between cost and duration, and one between defects and duration.
Project Portfolio Management
Planning: Abstract. IT departments are caught between a rock and a hard place these days. Budgets are shrinking while the dependence on IT products and services is increasing. The pressure to demonstrate that each new project will either save money, increase sales, or result in enterprise-wide efficiencies is greater than ever. And yet, the majority of Global 1000 companies are still choosing which projects get funding either by the first-come/first served method, the squeaky-wheel gets the grease method, or the most powerful sponsor method. Deciding which IT projects get funding should be based on more than just subjective judgment; rather, the project should be analyzed objectively, looking at a number of factors – cost of ownership, cycle time, quality, risk, and benefit(s) being just a few. By analyzing projects objectively, they can be more effectively prioritized. CIOs and IT managers can then make wiser and more insightful decisions about which projects should get funding and which should be either postponed or shelved.
Software Size Uncertainty: Abstract. Examination of currently-accepted software cost, schedule, and defect estimation algorithms reveals a common acknowledgment that estimated software size is the single most influential independent variable. Unfortunately, “The most important business decisions about a software project are made at the time of minimum knowledge and maximum uncertainty.” This includes minimum knowledge and maximum uncertainty about a software product’s effective size at the time when most estimating is done. Further complicating the issue of estimate uncertainty, in the author’s opinion, is the lack of a commonly-accepted taxonomy. This paper proposes definitions for and the relationship between two key contributors to software size uncertainty: growth and estimation process variability, both being distributions, the dispersions of which decrease as a function of project progress. |
|
|
Products
|
Services and Support |
Library
|
News
and Events |
Company |
Home
| FAQs
|
Search
| Contact
Us |
.gif)
.gif)
.gif)
.gif)