The complexity of software engineering called for significant work to identify best practices and avoid project failures. It gave rise to maturity models such as CMMI (Capability Maturity Model Integration) which, depending on the project activities or organizations, ascertain a level of maturity. It evaluates the capability of an organization to “standardize” software development activities as part of a continual improvement process. In this article, we suggest a maturity model for software estimation processes that is close to CMMI, but is not CMMI.
Software estimation processes: low-maturity levels
It is typical of organizations whose software estimation processes are barely defined. When asked “How do you estimate the cost of your projects?”, the answer usually is “We rely on the experience of project managers”.
That experience is rarely based on organized historical data. It is actually biased and may easily be questioned by managers. Because of the lack of unbiased data, the senior manager often has the final say.
Yet, an estimation approach lacking maturity will generate a low estimate (optimistic estimate). A low estimate often leads to project failure.
It mainly translates into delays and overspends and shows the company in a bad light. It causes additional management charges and useless stress.
A low-maturity organization evaluates a number of man-day, regardless of the volume of software to develop. It is the same as if you paid gas according to the time it takes to fill the tank rather than on the volume of gas you get.
In the case of a subcontracting relation, an immature estimation process will often lead to pick the lowest bidder.
To better understand the concept of maturity, let’s see a representation of each of those levels.
Level 1
The overall effort is estimated on top of one’s head, informally, with little to no objection. Little to no details are provided regarding the estimation. No feedbacks are available.
Level 2
The effort of the main activities is estimated by experts. There are gainsayers and a spreadsheet is filled. The overall effort of the project is the sum of the efforts of all the activities. The additional activities that are calculated through ratios are usually based on the development effort and unitary tests.
Level 3
The organization adopted a formal software sizing method, such as the Function Point analysis.
A few measurements of project reviews allowed to compare the size of the software to the development effort. The average productivity and the effort breakdown for each project activity are deduced from the sizing of the project reviews. The estimation model usually relies on only one parameter: the size. The effort is calculated as follows:
Effort = Size x productivity
Level 4
The organization defined different software estimation processes for each life cycle phase (macro-estimate, general requirements, details specifications, etc.). Those different software estimation processes implement several estimation techniques and software sizing methods (approximate measurement, formal measurement). Different productivities are identified according to technologies, locations, etc. The parametric estimation models include at least ten parameters.
The organization compares the expectations and the actual software to feed the historical data base.
Level 5
The organization makes the most of its historical data base to carry advanced analysis and improve its estimation models. The parametric models may include many parameters (sometimes dozens). Going from level 4 to 5 requires many data, and consequently, many project reviews. Level 5 may be hard to reach, because the more varied the projects are, the more project reviews are needed and the higher the price of improvement.
It is not always necessary to reach level 5. It mostly depends on economic stakes.
Conclusions
The maturity level of the estimation process will directly impact the life cycle of the project.
If the maturity level of the estimation process is low (1 or 2), estimates are usually undervalued.It tends to generate schedule errors, to call for extra resources causing significant additional charges, to increase monitoring from managers inducing stress and time waste, in addition of a deficient product.
Generally speaking, expert estimates are undervalued to up to 30% of cases.
Depending on the software method, going from level 2 to 3 does not require much effort. Some methods are really simple and turn out to be very efficient.
It is not always necessary to reach level 5. It can only be reached if all the software development processes (CMMI) reach high maturity first.
