In spite of the research in software project estimation techniques to estimate the effort and cost required to develop software; project estimation continues to be a difficult and erroneous process. The reason: software development is a highly intellectual activity and to quantify the effort of a creative work is complicated. However, when a project proposal is to be given to a prospective customer, the developer may not have the complete information on the proposed work, and hence the complexity cannot be estimated; but the effort has to be estimated and the proposal must to contain the cost of the project. Tough job!
Every organization and every project manager has to strive to improve the process of effort estimation of software projects. The best and the most accurate method is to use the past experience to intelligently guess (or guestimate) the effort required for future projects. This guesswork has to be done based on scientific methods.
We will study the various uncertainties in estimation, the models available for the estimation and the methods used practically. After an initial estimate, how the estimate can be fine tuned keeping in view the risks associated with the project is also discussed. The overall process definition for project effort estimation is shown in Fig. 1.
|
|
Uncertainties in Estimation
At the time of giving a project proposal, it is extremely difficult to give an accurate estimate of the time and the budget for the following reasons:
• The proposal has to be prepared based on preliminary (not detailed) discussions with
the client, and the requirements are not fully understood. Many assumptions are made
as regards the user requirements, the assumptions may turn out to be wrong later.
• The technical feasibility study carried out will not be full-fledged, some assumptions
may be made as regards the software design as well, and they may also turn out to be
wrong later.
• When unforeseen difficulties are encountered while doing the implementation,
additional manpower may have to be deployed resulting in higher budget, which is
not taken into consideration at estimation stage.
• Due to the complexity of the project, multiple teams may have to be formed later so
that these teams can work in parallel on different alternative designs.
• The client may ask for modifications in the specifications (in his view, ‘minor’
modifications).
• There may be manpower attrition in the middle of the project because of which there
may be time overrun and hence cost overrun.
• To avoid the ill effects of manpower attrition in the middle of the project, the
manager may take a decision midway to keep ‘backup’ engineers on the job, to be on
the safe side, resulting in cost overrun.
• The execution model chosen may have to be changed later which may result in higher
costs (particularly when off-shore execution model is chosen at first and changed to
on-site model later).
All these factors may cause a major difference between the estimates and actual values of effort and cost. If all these factors are taken into consideration while carrying out the estimation, then the estimation can be better. But then, managers tend to think of an ideal world: the client has given all the requirements correctly, my team is a dedicated team, the design is very easy to handle, etc. The project manager must consider the above uncertainties while carrying out the estimation.
Inputs for Project Estimation
Before estimation of the effort involved in the project execution (in terms of person months), the following information needs to be obtained:
• Is the prospective customer financially sound?
• Is the prospective customer casual or is the project a genuine
requirement?
• What is the budget allocated to the project by the customer?
• What are the payment terms of the customer—advance, interim
payments or deferred payment etc.
If the project is against a tender, who are the likely competitors?
• What are the terms and conditions for development, whether source
code needs to be given along with the executable code or whether
maintenance support is to be provided?
• What is the warranty period and whether the maintenance has to be
provided on site or can it be done from the developer’s premises?
• Is there a possibility of a long-term association with the customer? If
so, a slightly less profit margin would be ok.
• Are the specifications very clear, or any changes are foreseen—the
risks associated with the changes have to be accounted in the cost
estimation.
• Any new hardware or software tools need to be procured for the
proposed project, and whether the new hardware and software can be
used for other projects or not. If not, this cost has to be a part of the
project cost.
• Is the domain expertise available? If new people have to be recruited,
what to do with them after the project is completed?
All these factors make an impact on the project effort estimation.
Effort Estimation Methodologies
To estimate the effort required for a project in terms of Person Months (PMs), the most important parameter required is an estimate of the code size in a given programming language.
Estimation of code size is extremely difficult because
• Code size depends on the software tools to be employed (for example,
the code size in C is much more than in say, a DBMS front end).
• Code size estimation can be accurate if the project team worked on a
similar project earlier.
• If re-use is possible, code estimation will be different.
• Code size depends on various factors such as the design, usage of tools
for code generation, testing approaches etc.
Presently available effort estimation techniques, however, use the code size as the basic parameter.
Algorithmic Cost Modeling
For estimating the cost of a software project, the first step is to estimate the effort involved in development. This in turn involves estimation of the size of the code. For code estimation, the most scientific method is to use algorithmic cost modeling in which
a model can be built based on the past experience. Such models need to be developed by an organization and refined continuously.
The algorithmic cost model will be very useful technique for the project managers. These models are derived from the historical data of the projects.
If the effort is measured in Person Months (PMs), and the size of the project in KDSI (Thousands of Delivered Source Instructions), as per single variable model,
Effort = m * (KDSI)**n where m and n are constants.
An organization can determine its own values for m and n based on regression analysis of historical data i.e., take the actual values of effort and KDSI for the already executed projects and calculate the values of ‘m’ and ‘n’.
In IBM, 60 projects were analyzed. These projects ranged from 4 KDSI to 467 KDSI. Based on these projects, the following equation was arrived at:
Effort = 5.2 * (KDSI)**0.9 A similar study for small projects indicates that
Effort = m * KDSI + n where m and n need to be obtained based on historical data.
We can derive the general trend from these equations that the effort increases linearly with size of the project for small projects and there will be a non-linear growth for larger projects.
Constructive Cost Model (COCOMO)
The above model does not take into consideration the factors such as the complexity of the project, experience of team members etc., which affect the project effort and hence the time. COCOMO developed by Boehm takes into consideration these factors. COCOMO is the most widely used estimation technique for procedural languages. COCOMO II, a variation of the basic COCOMO, is used for object oriented programming languages. COCOMO II takes into consideration the process maturity of the organization in terms of the implementation of CMM framework. We will discuss the salient features of basic COCOMO here to get a flavor of effort estimation.
Basic COCOMO
For applying COCOMO, the project has to fall into one of the categories
a) Organic mode project: When the application is well understood and a small project
team can complete the project, it is called an organic-mode project. Most of the
application software packages development projects fall into this category.
b) Semi-detached project: When the development is more complex than an organic
mode project and the team members have limited experience of working on related
projects, the project is termed as semi-detached project. Development projects such as
networking software, telecommunications software etc. fall into this category.
c) Embedded project: When the development involves hardware, software and complex
operational procedures, the project is termed as embedded project. Projects such as
process control systems, network appliances, micro-processor/digital signal processor
based systems etc. are examples of this category of projects.
The effort estimated in terms of person months for each type of project is obtained using the formulae:
Organic mode projects: Effort (in PMs) = 2.4 (KDSI)** 1.05
Semi-detached projects: Effort (in PMs) = 3.0 * (KDSI) ** 1.12
Embedded projects: Effort (in PMs) = 3.6 (KDSI) ** 1.20
where KDSI = thousands of delivered source instructions
While calculating KDSI, the following points are to be noted:
(i) Comments are excluded.
(ii) If two or more instructions are on the same line, they are counted as a single DSL
(iii) If a statement spreads over n lines, they are counted as n DSI.
In Intermediate COCOMO, the effort estimated using the basic COCOMO is adjusted keeping in view the following attributes:
Products attributes: reliability, complexity of the product, database size.
Computer attributes: constraints imposed because of hardware platform e.g., execution time, storage constraints, stability of hardware, hardware on which the software has to run.
Personnel attributes: analyst capability, application experience, programmer capability, programming language experience.
Project attributes: use of tools, modern programming practice etc.
Schedule attribute: The time frame for the project execution.
For each attribute a value is assigned. The value is more than 1 if that attribute increases the effort and the value is less than one if that attribute decreases the effort. Consider a project for which the effort is estimated to be 120 PMs based on the above formula. Suppose that the project team is inexperienced in the required programming language. In such a case, the personnel attribute can be given a value of 1.2 and this value is multiplied by the effort calculated earlier (120 * 1.2 = 144 PMs). Similarly, for the other attributes values are assigned.
However, the drawback of COCOMO model is that for obtaining the effort required, the code size has to be estimated first. Estimating the code size is not an easy task. Hence, these estimation models are not widely used in many organizations. Sometimes, the programming language to be used is not decided even, in such cases, code size estimation has no meaning at all.
The most widely used estimation technique is to rely on expert judgment. A scientific approach is to obtain the estimates from different experts independently and compare the estimates and then arrive at the final estimate. This method is extensively used in commercial organizations. In this approach, the estimation of effort and duration go hand in hand.
However, it needs to be noted that the estimation of time is only to give an indication of the likely duration. Invariably the client will reduce the time frame. If you ask for 6 months, the client will negotiate for 4 months. You find yourself in a situation where you either accept the time frame or lose the project, and you always decide on the first choice.
The project manager has to always work with tighter schedules than anticipated. These “Internet Time” projects have become the order of the day. The only way one can manage such projects is to motivate the team members so that they can work longer hours and complete the project. If the software engineers throughout the world—whether in Boston or Bangalore or Tel Aviv work for 12 to 16 hours a day, many without weekends, it is because of this factor. As long as one does not burn himself/herself out and the health and family life are not affected, there is fun in such a work.
Estimation of Cost
If the effort in PMs is estimated using the estimation techniques described in the previous section, then estimation of the cost is easier as the effort has to be multiplied by the cost in dollars per unit effort (e.g., cost per person hour or person month). However, as discussed earlier, it is very difficult to arrive at the effort using the above techniques. A more practical approach is to divide the process into different activities and (or phases) and for each phase, estimate the number of person hours required and then calculate the cost of the project.
Table I gives the template for estimation of effort and cost based on the different activities.
|
Activity |
No. of persons |
No. of person months |
No. of person hours |
$ per hour |
Total |
|
Requirements |
|
|
|
|
|
|
Design |
|
|
|
|
|
|
Implementation |
|
|
|
|
|
|
Lab testing |
|
|
|
|
|
|
Beta testing/field trial |
|
|
|
|
|
|
Documentation (including translation service charges) |
|
|
|
|
|
|
Installation and commissioning |
|
|
|
|
|
|
User training |
|
|
|
|
|
|
Maintenance |
|
|
|
|
|
|
Management |
|
|
|
|
|
|
Senior management |
|
|
|
|
|
|
Administrative work |
|
|
|
|
|
Table I. Template for project effort and cost estimation
The cost per hour is obtained as the average cost of the engineers working on the project. However, the overheads of the organization (such as the cost of building/rent, electricity, employee overheads etc.) need to be considered for an employee. A thumb rule is to take 100% overheads i.e., if the average amount paid to an employee per hour is $20, the cost per person hour is $40.
After calculation of the cost for all the above activities, the costs for the development and administration are obtained. In addition, cost is incurred on the following heads which also needs to be added to obtain the project cost.
> Pre-order costs and marketing costs (tendering expenses, preliminary study at the
customer site, marketing agent commissions, referral fee etc.)
> Travel
> Communication costs
> Hospitality
> Hardware costs (if any specific hardware has to be procured for the project)
> Software costs (if any specific software has to be procured for the project)
> Consulting charges if expert consultants are hired for the project
> Incentives to be paid to the project team members after successful completion of
the project.
> Stationery (media for software distribution and manuals)
> Miscellaneous expenditure
Estimation of the project cost is one of the most difficult exercises because it is very difficult to foresee all the expenditure. In some projects, it may be necessary to try alternative methods and hence two teams may be made to work in parallel on the project. So, before finalizing the project cost, one needs to work out the possible risks associated with the project and then revise the costing.
Estimation of Workforce
Once the effort and the duration of the project are estimated, estimating the work force required (in terms of the number of people) is easy. To reduce costs, initially, few people can be put on the project, and as the project progresses, people need to be added up and the manpower reaches a peak. Once the software is delivered and maintenance phase is entered, again the manpower requirement goes down. For very large projects involving thousands of PMs, this approach of manpower build up is advisable.
For small projects involving a few hundred Person Months, it is better if the total team responsible for design and implementation is put in place along with those who obtained the systems specifications. This would speed up the development process.
Accounting for Risk Factors
For any project, the risks can be (a) cost risk (b) performance risk and (c) schedule risk. After an initial estimate of the effort, cost and time, the estimated values need to be refined taking into consideration the following aspects.
Once the effort is estimated, the manpower required in Person Months is obtained. In the software industry, the highest risk is associated with manpower. So, the project manager needs to take into consideration how the impact of manpower leaving in the middle of a project can be minimized. This is generally done either by increasing the manpower (to have enough backup) and/or by paying incentives. In both cases, the project estimates in terms of person months and cost need to be revised. It is preferable if the manpower is increased by 20% (the average attrition rate in the industry).
Another risk factor is the time. Generally, the time estimated would not be same as the time accepted with the client (it would always be less, obviously!). How to complete a project in less time than planned? Just by increasing the manpower, the time frame cannot be reduced—as you increase the manpower, the time is likely to increase as there will be too many communication paths. The only way to get the job done in time is to make the team work longer hours. In most of the software development organizations, it is very common for engineers to work 14 to 16 hours a day, with just a one-day weekend. This is a better approach than trying to increase the manpower to reduce time frame. In such a case, the team members need to be given monetary compensation. In addition, they need to be provided some recreation facilities within the organization premises.
Risks associated with the technical aspects also need consideration. If the project has some areas in which there is vagueness in specifications, or when the technical team has to try out different alternatives in design and implementation, correspondingly, the effort will go up, as two teams need to work on different alternatives. The effort estimation needs to be fine-tuned based on this aspect as well.
Based on the estimation process described here, the project manager can start estimation of the project effort, time and manpower. However, this process needs to be refined continuously. Once a project is completed, the project manager has to carry out a postmortem analysis and analyze the differences between the estimates and actual values of effort and cost under various heads. Based on the analysis, the project estimation process has to be refined.
