GUIDANCE
The Pricing Handbook

19. Software Pricing

19.1 Introduction

 

19.1 Introduction

Software is a set of programs and accompanying documentation that directs computers to perform desired functions. In simple terms, a software program is a set of instructions for a computer. Within the Federal Aviation Administration (FAA), for example, software controls air traffic control systems, drives simulators, directs surveillance systems, and controls accounting, inventory and Management Information Systems (MIS). Software is a critical component in virtually every current FAA system, and will grow in importance as future FAA systems are developed and fielded. Between 1982 and 2003, the FAA will spend $21 billion on software-intensive Air Traffic Control (ATC) information systems, according to the General Accounting Office (GAO) report, "Air Traffic Control: Improved Cost Information Needed to Make Billion Dollar Modernization Investment Decisions." Barry Boehm, in his book, Software Engineering Economics, suggests software costs are contributing to an increasing proportion of overall system costs. The FAA recognizes the need for accurate software estimates as well as performance measurement of software development programs. Software pricing is based upon the same steps as software cost estimating. Therefore, the software cost estimating process and techniques will be described first in this chapter and then the software pricing process. Those familiar with software cost estimating can jump directly to section 19.7, Software Pricing Process. Note also that the subjects of software work breakdown structure (WBS), software cost models, and commercial-off-the-shelf (COTS) software are dealt with in detail in Appendices C, D and E, respectively.

A significant portion of this chapter is drawn from the following sources: United States Air Force (USAF) software primer, Space Systems Cost Analysis Group (SSCAG), Software Methodology Handbook (published in June 1995), United States Navy’s Naval Command, Control, Surveillance Center, RDT&E Division Software Engineering Process Office (NRaD), Software Size, Cost and Schedule Estimation Process manual, dated June 1996; the National Aeronautics and Space Administration (NASA) Parametric Cost Estimating Handbook, dated Fall 1995m and DoD’s Software Technology Support Center’s (STSC) Report on Project Management and Software Cost Estimation Technologies, dated April 1995. These documents will be referenced in this chapter as SSCAG Handbook, NRaD’s Manual, NASA’s Handbook and the STSC Report respectively. The DoD community has extensive experience in the research and development of sophisticated software estimating tools and techniques. Although some DoD specific information is included, the concepts discussed are applicable in the FAA environment.

 

19.1.1 SEI Requisites

This chapter also embodies the philosophy of the Software Engineering Institute (SEI) as published in their "Checklists and Criteria for Evaluating the Cost and Schedule Estimating Capabilities of Software Organizations." SEI’s research has concluded that developing credible software estimates is a function of how thorough and disciplined an organization’s estimating processes are. Accordingly, SEI has developed six institutional process requisites that organizations in the business of building or acquiring software-intensive systems must possess if they are to consistently produce reliable cost estimates. The activities necessary to ensure that the SEI requisites are met span the software program life cycle and are discussed in this chapter. These requisites are listed below:

  • A corporate memory, or historical database(s), for cataloging cost estimates, revisions, reasons for revisions, actuals, and other descriptive information, such as any constraints or trends that affect the project;
  • Structured processes for estimating software size and the amount and complexity of existing software that can be reused;
  • Cost models calibrated/tuned to reflect demonstrated accomplishments on similar past projects;
  • Audit trails that record and explain the values used as cost model inputs;
  • Processes for dealing with externally imposed cost or schedule constraints to ensure the integrity of the estimating process; and
  • Data collection and feedback processes that foster capturing and correctly interpreting data from work performed.

19.1.2 Complexities of Software Cost Estimating

According to Richard D. Stutzke in his article "Software Estimating Technology: A Survey" in STSC’s Crosstalk magazine, the software cost estimation process is difficult for several reasons. The first problem is that projects often must satisfy conflicting goals. Projects to develop or maintain software must provide specified functionality within specified performance criteria, within a specified cost and schedule, and with some desired level of quality (absence of defects). Software engineering processes can be chosen to meet any one of these project goals. Usually, however, more than one goal must be satisfied by a particular project. These multiple constraints complicate the estimation process.
Why Software Cost Estimating is Difficult:
  1. Projects are frequently required to satisfy conflicting goals.
  2. Estimates are required before the product is well defined.
  3. Estimates are highly dependent upon software development processes.
  4. Software development processes are constantly changing. 

 

The second problem is that estimates are required before the product is well defined. Software functionality is difficult to define, especially in the early stages of a project. The basis for the first good cost estimate is usually not available for totally new systems until the top-level design has been defined. This level of design is only defined at the preliminary design review in many government contracts and sometimes not even then, which leads to undesirable consequences. This milestone is reached after about 20 percent of the total effort and 40 percent of the total duration have been expended by the project staff. At this point in a project, typical accuracies for the estimated effort and duration are within 25 percent of the final project actuals. In general, since more information becomes available, the accuracy of estimates increases as a project proceeds. To reduce costs, as well as to improve quality and reduce development times, some projects employ pre-defined "domain specific software architectures". The development costs for such projects can be estimated more accurately than for projects that build a totally new product since more information about the product is available earlier. In general, however, the estimator must apply considerable skill to estimate project cost and schedule early in a project.

More data are available for modifications of existing code than when the existing code was written, so more accurate estimates are possible for this kind of project compared to totally new development. A large portion of all software maintenance work is a response to changes in the original requirements or in the system's external environment (mission, interfaces to other systems etc.). Software processes must produce software that can be gracefully evolved at reasonable costs. The choice of the software architecture significantly influences modifiability and hence maintainability. New ways to estimate the costs of such projects continue to be developed.

Modification of code is closely tied to software reuse. Various cost estimation models have been developed to qualify the economic costs of building and using reusable components. For example, Richard Selby analyzed costs at NASA's Software Engineering Laboratory and found that there is a large increase in programmer effort as soon as a programmer has to "look inside" the component. The cost to reuse a component depends on its suitability for the intended application, its structure, and other factors. The cost to reuse software compared to the cost to develop new software is a function of the amount of existing code that must be modified to install the code in a new system. A model developed using data from Richard Selby, Gerlich Rainer, Ulrich Denskat and Barry Boehm, indicates several important aspects of reused software costs. First, the cost is not zero even if no code is modified. Second, the costs increase faster than linearly at first. Third, the cost to modify all of the existing code is more expensive than to develop the code from scratch. (Effort is wasted to understand, then discard the existing code before the new code is written. This effort is never expended if the decision is made to develop totally new code from the start.) For the worst case, the economic break-even point occurs when only 20 percent of the code is modified; reuse is not cost effective above the break-even point. Such nonlinear behavior was not handled in previous cost models.

A third complication arises because the nature of software building is changing. New development processes emerge and new ways are needed to estimate the costs and schedules for the new processes. These processes endeavor to provide higher quality software (i.e., fewer defects), produce more modular and maintainable software, and deliver software (products and prototypes) to the end user faster. To meet these and the other objectives (stated previously), developers use combinations of pre-built code components and labor-saving tools. For example, many programming tasks are being put into the hands of the users by providing macro definition capabilities in many products. These capabilities allow users to define sequences of frequently used commands. A slightly more sophisticated approach is to allow domain experts to construct applications using special tools such as fourth-generation languages and application composition tools. Larger systems intended for specialized (one of a kind) applications are often built using commercial-off-the-shelf (COTS) products to provide functionality in areas that are understood well enough to be standardized. Examples are graphical user interfaces and relational database management systems. The trend toward object oriented languages supports this by making it easier to develop "plug compatible" components. Thus, reuse of code becomes an increasingly large factor in cost estimation, and a good understanding of the cost factors associated with software reuse becomes even more important.

Lastly, R. Selby is one of the authors that advocate of "measurement driven development processes" wherein process activities are adapted during the course of a project based on measurements of process performance. Planning and costing such processes prior to the start of the project is impossible.

The pricing process, terms and principles are described in the other chapters of this handbook. Since software pricing is dependent upon an understanding of the software cost estimation process, this chapter will discuss the issue of software cost estimation. First, software itself is explained so that the reader may fully understand what costs are being estimated. Next, the software life cycle is described, which includes the software development and software support phases. The specifics of the software cost estimating process follow, which will contain sections on the software work breakdown structure, software sizing, and estimating methodologies. Following the discussion of cost estimating will be a discussion of the software price analysis and cost analysis process. Finally, a discussion of parametric cost models and project tracking and metrics is included.