Software Cost Estimation Tool and Its Utilization

Estimation: is intelligent anticipation of quantum of work that needs to be preformed and the resources (human resources, monetary resources, equipment resources and time resources) required to perform the work at a future date, in a defined environment, using specified method.

Software size: The amount of (quantity) of software that needs to be developed. Software development effort: The amount of effort, in either person-days or person-

hours, necessary for developing the software product of an estimated size. Software development cost: The expenses necessary for developing software of defined

size, including the expense of human effort. Software development schedule: the duration, in calendar days or months, that is

necessary for developing the defined amount of software.Thus we have the following deliverable from software estimation:

Components that make up the software, as well as their sizes. Effort required developing the software. Duration (schedule) required for developing the software.

Estimation techniquesThere is no simple way to make an accurate estimate of the effort required to develop a software system. You may have to make initial estimates on the basis of a high level user requirements definition. The software may have to run on unfamiliar computers or use new development technology. The people involved in the project and their skills will probably not be known. All of these mean that it is impossible to estimate system development costs accurately at an early stage in a project. Furthennore, there is a fundamental difficulty in assessing the accuracy of different approaches to cost-estimation techniques. Project cost estimates are often self-fulfilling. The estimate is used to define the project budget, and the product is adjusted so that the budget figure is realized. I do not know of any controlled experiments with project costing where the estimated costs were not used to bias the experiment. A controlled experiment would not reveal the cost estimate to the project manager. The actual costs would then be compared with the estimated project costs. However, such an experiment is probably impossible because of the high costs involved and the number of variables that cannot be controlled. Nevertheless, organizations need to make software effort and cost estimates. To do so, one or more of the techniques described in Fig # 1 may be used (Boehm, 1981). All of these techniques rely on experience-based judgments by project managers who use their knowledge of previous projects to arrive at an estimate of the resources required for the project. However, there may be important differences between past and future projects. Many new development methods and techniques have been introduced in the last 10 years. Some examples of the changes that may affect estimates based on experience include.

Distributed object systems rather than mainframe-based systems Use of web services Use of ERP or database-centered systems Use of off-the-shelf software rather than original system development Development for and with reuse rather than new development of all parts of a System.

Technique Description

Algorithmic costModeling

A model is developed using historical cost information that. relates some software metric (usually its size)to the project cost An estimate is made of that metric and the model predicts the effort required.

Expert judgment Several experts on the proposed software development techniques and the application domain are consulted.They each estimate the project cost These estimates are compared and discussed. The estimation process iterates until an agreed estimate is reached.

Estimation byAnalogy

This technique is applicable when other projects in the same application domain have been completed. The cost of a new project is estimated by analogy with these completed projects. Myers (Myers, 1989) gives a very dear description of this approach.

Parkmson's Law Parkinson's Law states that work expands to fill the time available. The cost is determined by available resources rather than by objective assessment. If the software has to be delivered in 12 months and 5 people are available, the effort required is estimated to be 60 person-months.

Pricing to win The software cost is estimated to be whatever the customer has available to spend on the project. The estimated effort depends on the customer's budget and not on the software functionality.

Fig # 1 Cost Technique Description Estimation techniques

Development using scripting languages such as TCL or Perl (Ousterhout, 1998) The use of CASE tools and program generators rather than unsupported software

development.If project managers have not worked with these techniques, their previous expenence may not help them estimate software project costs. This makes it more difficult for them to produce accurate costs and schedule estimates. You can tackle the approaches to cost estimation shown in Fig # 1 using either a mp-down or a bottom-up approach. A top-down approach starts at the system level. You start by examining the overall functionality of the product and how that functionality is provided by interacting sub-functions. The costs of system-level activities, such as integration, configuration management and documentation are taken into account. The bottom-up approach, by contrast, starts at the component level. The system is decomposed into components, and you estimate the effort required to develop each of I:hese components. You then add these component costs to compute the effort required for the whole system development. The disadvantages of the top-down approach are the advantages of the bottom-upapproach and vice versa. Top-down estimation can underestimate the costs of solving difficult technical problems associated with specific components such as interfaces to nonstandard hardware. There is no detailed justification of the estimate that is produced. By contrast, bottom-up estimation produces such a justification and considers each component. However, this approach is more likely to underestimate the costs of system activities such as integration. Bottom-up estimation is also more expensive. There must be an initial system design to identify the components to be costed. Each estimation technique has its own strengths and weaknesses. Each uses different information about the project and the development team, so if you use a single model and this information is not accurate, your final estimate will be wrong. For large projects, therefore, you should use several cost estimation techniques and compare their results.

If these predict radically different costs, you probably do not have enough information about the product or the development process. You should look for more information about the product, process or team and repeat the costing process until the estimates converge. These estimation techniques are applicable where a requirements document for the system has been produced. This should define all users and system requirements. You can therefore make a reasonable estimate of the system functionality that is to be developed. In general, large systems engineering projects will have such a requirements document. However, in many cases, the costs of many projects must be estimated using only incomplete user requirements for the system. This means that the estimators have very little information with which to work. Requirements analysis and specification is expensive, and the managers in a company may need an initial cost estimate for the system before they can have a budget approved to develop more detailed requirements or a system prototype. Under these circumstances, 'pricing to win" is a commonly used strategy. Thenotion of pricing to win may seem unethical and unbusinesslike. However, it does have some advantages. A project cost is agreed on the basis of an outline proposal. Negotiations then take place between client and customer to establish the detailed project specification. This specification is constrained by the agreed cost. The buyer and seller must agree on what is acceptable system functionality. The fixed factor in many projects is not the project requirements but the cost. The requirements may be changed so that the cost is not exceeded. For example, say a company is bidding for a contract to develop a new fuel delivery system for an oil company that schedules deliveries of fuel to its service stations. There is no detailed requirements document for this system so the developers estimate that a price of $900,000 is likely to be competitive and within the oil company's budget. After they are granted the contract, they negotiate the detailed requirements of the system so that basic functionality is delivered; then they estimate the additional costs for other requirements. The oil company does not necessarily lose here because it has awarded the contract to a company that it can trust. The additional requirements may be funded from a future budget, so that the oil company’s budgeting is not disrupted by a very high initial software cost. [1]

Software Cost Estimating Methods

The overall process of developing a cost estimate for software is not different from the process for estimating any other element of cost. There are, however, aspects of the process that are peculiar to software estimating. Some of the unique aspects of software estimating are driven by the nature of software as a product. Other problems are created by the nature of the estimating methodologies. Software cost estimation is a continuing activity which starts at the proposal stage and continues through the lift time of a project. Continual cost estimation is to ensure that the spending is in line with the budget. Cost estimation is one of the most challenging tasks in project management. It is to accurately estimate needed resources and required schedules for software development projects. The software estimation process includes estimating the size of the software product to be produced, estimating the effort required, developing preliminary project schedules, and finally, estimating overall cost of the project. After 20 years research, there are many software cost estimation methods available including , estimating by analogy, expert judgment method, price to win method, top-down method, and bottom-up method. No one method is necessarily better or worse than the other, in fact, their strengths and weaknesses are often complimentary to each other. To understand their strengths and weaknesses is very important when you want to estimate your projects.

1. Expert Judgment MethodExpert judgment techniques involve consulting with software cost estimation expert or a group of the experts to use their experience and understanding of the proposed project to arrive at an estimate of its cost. Generally speaking, a group consensus technique, Delphi technique, is the best way to be used. The strengths and weaknesses are complementary to the strengths and weaknesses of algorithmic method. To provide a sufficiently broad communication bandwidth for the experts to exchange the volume of information necessary to calibrate their estimates with those of the other experts, a wideband Delphi technique is introduced over standard Delphi technique. The estimating steps using this method:

1. Coordinator present each expert with a specification and an estimation form.2. Coordinator calls a group meeting in which the experts discuss estimation issues with the

coordinator and each other.3. Experts fill out forms anonymously4. Coordinator prepares and distributes a summary of the estimation on an iteration form.5. Coordinator calls a group meeting, specially focusing on having the experts discuss

points where their estimates varied widely.6. Experts fill out forms, again anonymously, and steps 4 and 6 are iterated for as many

rounds as appropriateThe wideband Delphi Technique has subsequently been used in a number of studies and cost estimation activities. It has been highly successful in combining the free discuss advantages of the group meeting technique and advantage of anonymous estimation of the standard Delphi Technique. The advantages of this method are:

The experts can factor in differences between past project experience and requirements of the proposed project.

The experts can factor in project impacts caused by new technologies, architectures, applications and languages involved in the future project and can also factor in exceptional personnel characteristics and interactions, etc.

The disadvantages include: This method cannot be quantified. It is hard to document the factors used by the experts or experts-group. Expert may be some biased, optimistic, and pessimistic, even though they have been

decreased by the group consensus. The expert judgment method always compliments the other cost estimating methods such

as algorithmic method.

2. Estimating by AnalogyEstimating by analogy means comparing the proposed project to previously completed similar project where the project development information id known. Actual data from the completed projects are extrapolated to estimate the proposed project. This method can be used either at system-level or at the component-level. Estimating by analogy is relatively straightforward. Actually in some respects, it is a systematic form of expert judgment since experts often search for analogous situations so as to inform their opinion. The steps using estimating by analogy are:

1. Characterizing the proposed project.2. Selecting the most similar completed projects whose characteristics have been stored in

the historical data base.

3. Deriving the estimate for the proposed project from the most similar completed projects by analogy.

The main advantages of this method are:1. The estimation are based on actual project characteristic data.2. The estimator's past experience and knowledge can be used which is not easy to be

quantified.3. The differences between the completed and the proposed project can be identified and

impacts estimated.However there are also some problems with this method,

1. Using this method, we have to determine how best to describe projects. The choice of variables must be restricted to information that is available at the point that the prediction required. Possibilities include the type of application domain, the number of inputs, the number of distinct entities referenced, the number of screens and so forth.

2. Even once we have characterized the project, we have to determine the similarity and how much confidence can we place in the analogies. Too few analogies might lead to maverick projects being used; too many might lead to the dilution of the effect of the closest analogies. Martin Shepperd etc. introduced the method of finding the analogies by measuring Euclidean distance in n-dimensional space where each dimension corresponds to a variable. Values are standardized so that each dimension contributes equal weight to the process of finding analogies. Generally speaking, two analogies are the most effective.

3. Finally, we have to derive an estimate for the new project by using known effort values from the analogous projects. Possibilities include means and weighted means which will give more influence to the closer analogies.

It has been estimated that estimating by analogy is superior technique to estimation via algorithmic model in at least some circumstances. It is a more intuitive method so it is easier to understand the reasoning behind a particular prediction..

3. Top-Down and Bottom-Up Methods3.1 Top-Down Estimating Method: Top-down estimating method is also called Macro Model. Using top-down estimating method, an overall cost estimation for the project is derived from the global properties of the software project, and then the project is partitioned into various low-level components. The leading method using this approach is Putnam model. This method is more applicable to early cost estimation when only global properties are known. In the early phase of the software development, It is very useful because there are no detailed information available.  The advantages of this method are:

It focuses on system-level activities such as integration, documentation, configuration management, etc., many of which may be ignored in other estimating methods and it will not miss the cost of system-level functions.

It requires minimal project detail, and it is usually faster, easier to implement.The disadvantages are:

It often does not identify difficult low-level problems that are likely to escalate costs and sometime tends to overlook low-level components.

It provides no detailed basis for justifying decisions or estimates.Because it provides a global view of the software project, it usually embodies some effective features such as cost-time trade off capability that exists in Putnam model. 

3.2 Bottom-up Estimating Method: Using bottom-up estimating method, the cost of each software components is estimated and then combines the results to arrive at an estimated cost of overall project. It aims at constructing the estimate of a system from the knowledge accumulated about the small software components and their interactions. The leading method using this approach is COCOMO's detailed model. The advantages:

It permits the software group to handle an estimate in an almost traditional fashion and to handle estimate components for which the group has a feel.

It is more stable because the estimation errors in the various components have a chance to balance out.

The disadvantages: It may overlook many of the system-level costs (integration, configuration management,

quality assurance, etc.) associated with software development. It may be inaccurate because the necessary information may not available in the early

phase. It tends to be more time-consuming. It may not be feasible when both time and personnel are limited.[2]Summary: In this we discussed the various steps in Software Cost Estimation Tools and Software Cost Estimation Methods. We also discussed some of the popular techniques and industry best practices for Software Cost Estimation that tells us how measure our Software cost.

References:1. Ion Sommerville Software Engineering 8th Edition Ch#26 (Page # 518-520).2. School Of Computing Dublin City University (DCU)

http://www.compapp.dcu.ie/~renaat/ca421/LWu1.html