# Can you use the Software Equation to get LOC output?

The Software Equation is:

E is effort in man months or years.
P is the "productivity parameter."
B is the "special skills factor."
t is length of project measured in months or years.

Now, I'm thinking that since E is in man-months, it's equivalent to nt, where n is the number of people working on the project. Substituting nt, and solving for LOC gives me this equation: LOC = (n*P^3*t^5/B)^1/3

This doesn't seem right because of the t^5 factor. It seems to be saying that the rate of output in LOC increases as time goes on, and the opposite seems to be true in real projects.

What am I missing here?

• Something that might help is that B is a function of LOC. Unfortunately, I don't know what the function is (or even if it's well defined, other than the piecewise function defined at Wikipedia in the article you linked to). Depending on what the function of B is, that might reduce t to something that makes more sense. However, all of this might be in vain anyway, since this equation is designed to model effort. Size is dependent on requirements (and, for documentation, the process methodology) and can be estimated. Using that estimation, the idea is to compute effort. Apr 24, 2012 at 10:42
• I suppose it might be a good idea to ask what, exactly, you hope to accomplish by solving the software equation for size. There's probably a better way to get to that solution than playing around with the software equation. Apr 24, 2012 at 10:45
• @ThomasOwens I'd like to be able to estimate the rate of output of a workforce on a project (say LOC/day, week, year, whatever), given the number of people working on it, attributes of the project (B and P for example), and how far along they are in the project (time passed working on the project). Just out of curiosity, not for application in the real world. Apr 25, 2012 at 19:08
• I need to think about this some more, but on a real project, you tend to estimate the effort and duration and measure productivity and progress. I think the answer might be that you aren't missing anything, but the research is designed to support real projects where you aren't estimating output, but output is a known value. Apr 25, 2012 at 20:35
• Lines of code don't map directly to features delivered or to technical complexity. Some languages are simply more verbose than others, which may impact the usefulness of your results. Oct 15, 2012 at 17:36