19.3 Software Cost Estimating Process

19.3.1 Process for Software Estimation Activities

19.3.2 Software Development Standards

19.3.3 Benefits of SW Estimation Process

19.3 Software Cost Estimating Process

The overall process of developing a cost estimate for software is no 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. Many of the problems that plague the software development effort itself are responsible for the difficulty encountered in estimating that effort.

One of the first steps in any estimate is to understand and define the system to be estimated. Software, however, is intangible, invisible, and intractable. It is inherently more difficult to understand and estimate a product or process that cannot be seen and touched. Software grows and changes as it is written. Also, when hardware design has been inadequate, or when hardware fails to perform as expected, the "solution" is often attempted through changes to the software. This change may occur late in the development process and sometimes results in an unanticipated software "build." In this type of situation, where the product is highly ambiguous, it is more important than ever to develop graphical representations of the final software product. This could be as simple as creating a product tree line drawing to represent the software development effort, or developing a software work breakdown structure (WBS), which is discussed in section 19.3.1 and 19.3.3. Other problems are created by the metrics used to size software and the nature of the software estimating methodologies themselves. These topics are discussed in sections 19.4 and 19.5, respectively.

Per NRaD’s Manual, projects should produce and document project plans, which include estimates of product size, resources, staffing levels, schedules, and key milestones. Historically, the costs and schedules for most software projects have been greatly underestimated. There are many reasons for this: costs and schedules are often pre-determined by an outside source; a real in-depth analysis of the software development process was not taken into consideration or in many cases not fully understood; and there is a general lack of acceptance of the concept that developing software is an expensive endeavor.

The software estimation process in the following sections describes the steps required for establishing initial software Life Cycle Cost (LCC) estimates and then tracking and refining those estimates throughout the life of the project. Establishment of this process early in the life cycle will result in greater accuracy and credibility of estimates and a clearer understanding of the factors that influence software development costs. This process also provides methods for project personnel to identify and monitor cost and schedule risk factors.

Following the sections on software cost estimating will be a discussion of the software price and cost analysis process. Software pricing is dependent upon most of the same input parameters that are required to perform a valid cost estimate. The objective of price analysis is to determine if the cost estimate contained in the contractor’s proposal is fair and reasonable. The objective of cost analysis is to analyze the cost elements contained in the contractor’s proposal to form an opinion on the degree to which individual cost elements and associated proposed profit or fee represent what the work should cost, given reasonable economy and efficiency. It involves a review of the judgment factors used in projecting the estimated costs. Therefore an understanding of the software cost estimating process is necessary for performing software pricing.

19.3.1 Process for Software Estimation Activities

Referring to NRaD’s Manual, software estimation is a continual process that should be used throughout the life cycle of a project. The process activity for developing the cost estimate is shown before the schedule estimate in Figure 19-7 because this is the sequence often used by the cost models. However, a development schedule is often mandated before the scope of the effort is clearly understood. The early establishment of a WBS helps to divide the effort into distinct work segments that can be scheduled and prioritized. A sample detailed software WBS is provided in Appendix 19C.

Figure 19-7. Software Cost Estimation Process

The following subsections provide an overview of the steps used to develop a thorough software project estimate. Detailed explanations of estimation requirements for each phase of a project are in subsequent sections. Detailed explanations of specific estimation methods and automated tools are contained in section 19.5 and Appendix 19D respectively.

STSC’s Report states that software estimation should be approached as a major process; it should be well planned, reviewed often, and continually updated. The basic steps required to accomplish software estimation are:

Step 1: Identify project objectives and requirements

The key point that needs to be made here is that project objectives and requirements must be clearly and precisely identified to develop good estimates of effort and costs early in the project's life cycle. The objectives of the project define what the end product is, what the end product's intermediate steps are, and when and for whom the project will be accomplished. The objectives also help define how and by whom the project will be carried out. Constraints are restrictions that affect the completion of project objectives. Constraints may arise from several factors. The start date or completion of the project may impose constraints. Other constraints are imposed by the application of specific resources and their associated availability. Constraints can also be policies and procedures that require justifications or explanations of implementation actions.

NRaD’s Manual states that defining requirements early on in a project can be a very difficult task. However, without knowing what the requirements are, it is impossible to accurately estimate a project's cost and schedule. If all of the requirements are not known, then the estimate should be based on the known requirements and make sure everyone understands that the estimate is based on only those known requirements. If using an incremental or evolutionary development strategy, then base the estimate on the requirements that have been defined for that increment.

Step 2. Plan the activities

The Work Breakdown Structure (WBS) is created in this step and is used in the software estimation steps that follow. WBS is an excellent tool for visualizing the software product. The WBS need not be complex, nor does it need to be highly detailed. The hardware WBS can be a useful tool in developing the initial WBS for software. There is usually a software CSCI or similar module associated with each HWCI. As the program evolves, the initial or draft WBS should include all software associated with the program regardless of whether it is developed, furnished, or purchased. If furnished or purchased software were omitted, it would not be possible to capture the cost of integrating pre-existing or purchased software with the development software. Appendix 19C contains a sample software WBS.

During each of the phases of software development, numerous activities will be performed in disciplines such as software development, software project management, software configuration management, and software quality assurance. As discussed by Boehm and by Donald J. Reifer in his SoftCost-R User's Manual, the activities performed for each discipline during each phase can be organized into an activity WBS for each CSCI. This WBS can be used with the product WBS as a basis for management reporting and tracking for a CSCI. A manager must understand that a software WBS contains different activities than a traditional hardware WBS (e.g., coding versus fabrication).

The WBS should depict only major software functions, and major subdivisions. It should not attempt to relate the software to the hardware it controls. Each of the major software functional units can be modeled as a CSCI. Lower level WBS elements can be modeled as a component. Once the WBS is established, the next step is to determine the magnitude of the software development/support effort and decide on which estimating technique should be used for deriving the estimate.

Step 3. Estimate product size

STSC’s REPORT describes how using the requirements and WBS, the product size can be estimated by estimating the sizes of the components identified in the WBS. Estimating product size is the basis of software cost estimation. Size is considered by software project managers to be a major technical performance or productivity indicator allowing them to track a project during development. Estimating product size is not simple to do; typically, it is very dependent on the experience of the persons doing the estimating. Since estimating size is so important to the overall cost estimate, section 19.4 describes in detail the various methods to estimate product size.

Step 4. Estimate Cost And Effort

Using size estimates as input, estimates of cost and effort are prepared. Many methods can be used (see Section 19.5), and the use of more than one method is strongly recommended. It is in this step that software estimation tools should be used to assist with the estimates. Many of the available tools use models that have been developed over the years using historical data from hundreds, even thousands, of projects. One widely used model is the COnstructive COst MOdel (COCOMO). For information on individual models see Appendix 19D.

In the NRaD Manual, the first consideration in estimating cost and effort (man-hours or man-months) is to choose the estimation method. If a parametric cost model (see Appendix 19D) is being used, then the environmental parameters for the project must be determined and entered into the model.

Examples of parameters are program complexity, programming language, requirements volatility, analyst capability, and execution time constraint. The estimate should include all labor activities charged directly to the task. These activities normally include:

• Engineering labor charges for System/Software Requirements Analysis, Design, Code, Test, and Integration.
• Documentation effort
• Configuration Management
• Software Quality Assurance
• Management effort charged directly to the task

Step 5. Estimate schedule

Using estimates of cost and effort, a tentative, projected schedule is developed. Continuing with the NRaD Manual, Schedule Estimates can be derived either manually or by using automated estimation models. A combination of both manual and automated methods is recommended. Manual methods should be based primarily on past experience. One or more software engineers with experience with the specific application under development should develop a schedule estimate as follows:

• The WBS should be expanded to delineate the order in which functional elements will be developed. The order of development will define which functions can be developed in parallel as well as dependencies that drive the schedule.
• A development schedule should be derived for each set of functions that can be developed independently, i.e., a schedule for each build of an incremental development.
• The schedule for each set of independent functions should be derived as the aggregate of the estimated time required for each major phase of the development: analysis, design, code & unit test, integration and test.
• The total project schedule should reflect the aggregate of the product development, including documentation and formal review requirements.

The steps outlined above are typical of manual estimates. Most of the available tools provide a standardized schedule estimate based on waterfall milestones shown in Figure 19-1. Automated tools allow the user to tailor the schedule in order to observe the impact on cost. However, most automated tools allow only a small amount of flexibility in shortening schedules. REVIC (REVised Intermediate COCOMO), for instance, allows the user to shorten the schedule by 25% from the nominally derived schedule.

Step 6. Risk Assessment

The STSC Report states that all known risks associated with a software development project should be defined and weighed, and impacts to the project costs should be determined. This information should always be included as part of the software estimation process. Poor software estimates generally result from four major risk areas, which are shown in Table 19-3.

Table 19-3. Risk Resulting from Poor Software Estimates