If you do not plan where you are going you will not get there, but you will probably get what you deserve. This software development model, that accurately predicts resources and schedule given scope, can greatly help planning when you will get there and what will be needed on the way. This may not be a perfect model, but perfection is the enemy of the good. What software development model experience can you share?
In a previous posting Innovation != R&D$, I reasoned that the impact of R&D expenditure is not well correlated with gross operating margins because a significant proportion of R&D monies is absorbed by the less revenue generating activities of maintenance and support rather than innovation, by which I mean in this context the creation of new software applications. However it is still important to ensure that whatever monies are invested in innovation are wisely invested. Unfortunately our industry is beset with project delivery problems. We have earned the IT Rule-of-5: 5 times over-budget, 5 times schedule, 1/5th functionality. Perhaps an exaggeration but there is a problem that few would deny.
One problem is that of creating unrealistic expectations. The development team’s answer to a feature request of ‘it is just a small matter of programming’ (one unit of SMOP) gets heard as ‘it will be on my desk tomorrow morning, tested and with a quality and quantity of documentation that would shame Charles Dickens’.
The answer is a good looking model. I love models. Not the type you are thinking of, but simple mathematical formulae that allow me estimate what will happen. Having been long involved with automation, MES, and software development I always want to know how long a software development will take. ‘As long as a piece of string’ is not the most useful answer when customer expectations or development budgets need to be met. So over the years I have developed a model that estimates total development effort and tracks development progress over the life-cycle of the project with surprising accuracy. Before you say that most models have so many ‘tuning factors’ that you can of course make it always fit, I want to point out that this model has just one factor. Also I want to point out that most of this model originates with Capers-Jones seminal work ‘Applied Software Measurement’
Estimating Model
The objective of the estimating model is to use a measure of the size of the development and come up with estimates for project duration, the number of project resources, total development effort and average productivity. From these estimates the project cost can be derived.
Tuning factor (J)
This is the only factor you need for this model. Fortunately Capers-Jones also provides a range of suggested values, as shown below. I would suggest 0.4 as a starting point.
| Kind of software | Best in class | Average | Worst in class |
| Systems | 0.43 | 0.45 | 0.48 |
| Business | 0.41 | 0.43 | 0.46 |
| Shrink-wrap | 0.39 | 0.42 | 0.45 |
Estimated Scope (LOC)
Estimated size for the project (lines-of-code). OK, it can be difficult to come up with a really accurate estimate, but there is much written on the subject. Quick ways are to simply say that this application is approximately the same size as a similar one done in the past. For greater accuracy, Function Point or Story Point estimating can be used and then converted to lines-of-code.
Estimated Function Point (FP)
= Lines-of-Code (LOC) / LOC-per-FP, where LOC-per-FP is taken as 54 for languages such as C#
Estimated Project Duration (D)
= FPJ (months)
The ideal project duration given the ideal number of resources for the project.
Development Resources (R)
= FP2*J/27 (persons)
The ideal number of full-time project-persons to complete the project.
Total development effort (Effort)
= D * R (person-months)
Average Productivity (P)
= LOC/Effort (lines-of-code per person-month)
Below is an example of applying this model to an example project:
| Development Estimate Model | |||
| Factor | Units | Formula | Example Project |
| Tuning Factor | dim | J | 0.4 |
| Lines of Code | LOC | LOC | 75000 |
| LOC/FP | LOC/FP | LOC-per-FP | 54 |
| Function Points | FP | FP | 1389 |
| Estimated project duration | months | FPJ | 18 |
| Development resources | persons | FP2*J/27 | 12 |
| Total development effort | person-months | FP3*J/27 | 219 |
| Average productivity | LOC/person-month | 27*FP (1-3*J) | 343 |
The graphs below shows the project effort and productivity plotted for various sizes of project. As would be expected we can see the productivity falling off as project size increase (see Mythical Man Month)
Tracking Model
The Tracking Model recognizes that the assumptions in the original estimate might not apply in practice. For example the number of resources assigned to the project might change, or the scope decreases or, more likely, increases. Thus the tracking model uses known measurements of the project such as code produced to date, resources actually assigned, and current total project size to calculate what the progress to date should be and to predict into the future the revised project completion.
Estimated Scope (LOC)
Estimated size for the project (lines-of-code). This is the estimate at the beginning of the project because scope creep and scrope additions will inevitably occur.
Scope Creep (Creep)
Percent change month-on-month of the project scope (%). This requires careful measurement because, as has been shown elsewhere, projects can only tolerate a small amount of scope creep before they become ‘runaways’.
Estimated Scope including creep (ELOC)
= LOC * (1+Creep) + Any additional scope
Estimated Scope (EFP)
= ELOC / LOC-per-FP
Project Duration (D)
Duration of project, measured from the original project start, assuming optimal resource allocation, no scope creep, and sustained productivity
= EFPJ
Required Project Resources (R)
Resources that should be allocated to the project for the duration
= EFP2*J/27
Actual Project Resources (AR)
Actual person-month assigned to the project for the period.
Estimated productivity (P)
Estimated lines-of-code per assigned person-month. Note that productivity reduces as the assigned resources increase (see Mythical Nan Month)
= ELOC*27*(27*AR)(1-3*J)/(2*J)
Estimated Production (PR)
Estimated lines-of-code produced in period based on assigned resources and estimated productivity.
= P * AR
Accumulated lines-of-code (ALOC)
Accumulated lines of code to-date based on assigned resources and estimated productivity.
Remaining Scope
Estimated scope less estimated accumulated code
= ELOC – ALOC
Accumulated Cost (AC)
Cost of actual resources assigned based on annual rate.
Cost per Line-of-code
A metric indicating how much each line-of-code is costing
= Accumulated Cost / Accumulated lines-of-code
Agile Productivity Ratio
The promise of Agile/SCRUM is that productivity will increase as large teams as split into Scrum teams. As indicated before, productivity reduces as team size increases. This is the ratio of the productivity of a single team versus multiple Scrum teams with the same total resources.
Allowable scope change
Scope creep is a project killer. If each month the project scope is allowed to increase, then the project size will increase. If the project size increases, then duration and number of project resources follow. As project resources increase then productivity will reduce, further decreasing project duration. As project duration increases, then more scope changes can accumulate, further increasing project duration, and so on. The tipping point when the project becomes a runaway has been determined and is calculated as follows:
= 1/EFPJ
The graphs below show the results from a typical project. We see the project scope increasing (scope-creep), resulting in more resources being pulled in to tackle the retreating deadline. Note that without scope creep the project would have completed in month 23 even with the same assigned resource profile. This signals the hidden dangers of even mild scope-creep.
The above graph is based on the actual resources assigned. The graph below compares the estimated with the actual production of code over the same period, confirming the accuracy of the model.
Observations
- Although there is only one factor in this model, estimates are quite sensitive to the value chosen. Therefore it is best to track the estimates with actual measurements to ensure the accuracy of the model and hence the tuning factor.
- Include test code or not? If the development teams are using test-driven development (TDD) or any form of Agile/SCRUM then I think it is important to include test code along with production code in the estimates, at the same time including the test resources with the overall project resources. Generally I expect to see test code lines-of-code to be approximately 50% of the production code.
- Counting lines-of-code should use the same tool, such as Visual Studio, for consistency. There is much debate about what should be included and excluded. However I think it is more important to simply be consistent because you will end up deriving your own tuning factor based on your assumptions.
- There is a difference between development productivity, and productivity of customer expectations. Just because the lines-of-code have been efficiently produced, albeit error free and with great documentation, it does not mean that customer expectations have been met because they might have wanted an entirely different solution.
- Scaling lines-of-code to function points. Despite the superiority of Function Points (or Story Points) over lines-of-code as a measure of software size, lines-of-code seems to be more tangible to management. Thus although the model is expressed in function points, I expect most will estimate lines-of-code or convert (‘back-cast’ to quote Capers-Jones) from lines-of-code to function points using a factor based on the type of programming language being used. For example there are approximately 54 C# lines-of-code per function point.
Associated Spreadsheet
To those who have got this far, I am sharing a spreadsheet version of this model that you are free to download and use for your own estimating. I hope it works as well for you as it has for me.
References
- Applied Software Measurement: Global Analysis of Productivity and Quality. Third Edition; Capers Jones; 2008
- The Mythical Man-Month: Essays on Software Engineering; Frederick Brooks;1995