The Parametric Model Approach

Sometimes a linear model seems too simplistic. Progress depends on more than the passage of time. There are so many variables that a linear model ignores, and surely these variables have an effect. Of course, if the variables are constant in the reference system and the system being estimated, they don’t need to be explicitly modeled. They’re implicitly included in the reference system.

If some of the variables differ between your reference system and the system being estimated, though, then it may well be worthwhile to account for them. That’s especially true if these variables change over time during the project. If you double the number of people working on the project halfway through, you don’t expect your rate of progress to remain the same. Nor do you likely expect your rate to double. The overhead of people working together goes up, too, so you’ll want to figure out what coefficient to multiply “number of people” by to accurately express the average rate of work. (You might even want to account for the initial drop in efficiency when suddenly adding people to the project. Or not—by the time you calculate that, it may be too late to worry about it.)

A parametric model calculates progress based on other parameters in addition to time. To make our past and projected progress fit a simple linear model, we presumed a known set of small functional slices of work that could be completed at a constant rate. Even when you consider “estimated story size” in your model, you’re starting to tread on the boundary of the basic linear model. You’re modulating it with a subjective sense of size or difficulty. The objective components of this subjective composite may be hard to isolate. What makes this story seem like a “5” rather than a “2” to you? Can you identify and use some of these components rather than the more subjective Story Point estimate?

Perhaps this story requires implementing a complicated algorithm that makes it seem bigger. And that one might have an unusually high number of permutations that need to be checked. And another has a lot of potential error conditions. Such things can make a story seem bigger. What parameters would you add to your model to let it calculate how much bigger the story could be? How can you quantify how complicated is the algorithm? Do you determine and count the number of permutations to check, or just use the factorial of the number of inputs? Can you be sure to count all of the error conditions?

You can build a sophisticated parametric model based on things you can count. Think back to the aspects of the work mentioned in ​Aspects of the System to Consider​. What can influence the size of a system? There are things like the number of user input screens, the number of database tables to hold the domain schema, the number of external interfaces to other systems (perhaps divided into input, output, and bidirectional interfaces), and other aspects of the system you’re building. These parameters may have a nonlinear effect, so the model may get quite complicated. What effect might each parameter have on the system size?

In our linear model, we assumed a constant rate of progress that we’d seen in the past. It could be that aspects of the system context (see ​Aspects of the System Context to Consider​) affect the rate of progress and could be different from our reference data. Does the number of teams or people working on the implementation vary? Are parts of the system similar to what you’ve already built and other parts unfamiliar territory? Does the system specifier sometimes change their mind, or delay in answering questions that are blocking the completion of work? There are many parameters that affect development rate.

Capers Jones’ model uses many inputs related to either size or development rate, and sometimes to both. The principle size measurement starts with Function Points, themselves a model counting the system’s inputs, outputs, inquiries, logical files, and interfaces to other systems. Defect insertion rate both increases the size of the effort and slows it down, as finding the origin of defects is time-consuming. On top of that is the defect removal efficiency and the bad fix rate, or new defects injected in the process of fixing a defect. The capabilities and experience of the people involved has a great deal of influence on the rate of accomplishment. Typically, creeping requirements increase the size of the work over the lifetime of the project.

The development methodology used will also affect the rate of development and perhaps the size, also, though in ways that are not easily quantified. Capers Jones’ model is clearly built with a phased serial process in mind, separately sizing the work products of requirements, analysis, design, coding, testing and installation phases, plus ancillary efforts such as project management, documentation, change management, and clerical support. The model offers a parameter to adjust for other methodologies in relation to this base assumption. There are also model dependencies on type of system being developed, quality level desired, implementation language, and software complexity. These are most of the items in the big picture, though there is much detail for each of them.

Capers Jones warns that the estimate you produce should be very conservative, to avoid litigation or protect yourself if you fail to avoid it. This suggests estimating to extremely high confidence levels, and therefore on the long and expensive side of every question.

How are these variables used to produce an estimating model? By analyzing a very large number of projects in a number of industries by a number of companies. By determining a best fit of all the input data of those projects to the corresponding actual results, a mathematical model is constructed to cover any potential project, to the extent that the data is known.

Models Are Only as Good as the Data They Model

Unpleasant details of troubled projects are often omitted from public descriptions of them to protect the reputations of people and companies. Perhaps the model is also adjusted for the estimated amount of inaccuracy in the calibration data; perhaps not. We noted the problem of ​Inaccurate Recorded Data​ when considering Comparison-Based Estimation. The same issues apply when the comparison is encoded into a mathematical model.

You can buy this model as part of an automated estimation tool. Do you think it will match your actual results? Perhaps it will, especially if you’re in the business of contract software development for government or large corporate customers. If you think it will help, and you can afford both the tool and the effort to collect and calculate the input data, then a commercial tool calibrated by someone else may be a good way to go.

The further your situation from the context in which such a commercial estimating tool was developed, the more it seems better to roll your own model. You don’t need to model every possible type of system by every possible way of building it. Instead, many of these inputs are relatively stable between the reference systems they use to construct the model and the system development they are estimating. These things that don’t change don’t need to be explicitly modeled. That is, as long as they truly don’t change.

Rolling your own model has some advantages. It lets you take into account the aspects you think are important. Beware of trusting models built for a different situation. They would likely be less helpful than a commercial model in terms of appropriately modeling your situation. Consider the inputs used by the commercial models and any other aspects that you think may be appropriate. Build your model slowly, as modifications to a linear model where that seems insufficient. Calibrate often and check against the results. Make sure your model is actually better for your needs than a simple linear model.