GUIDANCE
The Pricing Handbook

19. Software Pricing


19.6 Life Cycle Costs

 

19.6 Life cycle Costs

In addition to the costs associated with software development, the costs for the Contract Data Requirements List (CDRL) items such as manuals, specifications, plans, reports and training, plus the maintenance of the system after it becomes operational needs to be considered for the complete Life cycle costs of the project.

19.6.1 CDRL Deliverables Estimates

As summarized in the Cost Xpert User’s Manual, many models provide an estimate of the deliverables (such as the Software Requirement Specification (SRS)) that should be produced (based on the software development standard used, (see section 19.3.2) and an estimated page count. The page count is useful for two reasons. First, if the delivered document deviates significantly from the estimated page count, it raises the question whether the document is sufficiently complete. Second, the numbers are useful when planning to review documents in order to estimate the magnitude of the work that will be required. Capers Jones determined that on the average, companies spend between 2 and 4 hours per document page for technical documents.

 

19.6.2 Software Maintenance Estimates

The SSCAG Handbook defines the term "software maintenance" as those software engineering activities that occur following delivery of a software product to the customer. The maintenance phase of the software life cycle is the time period in which a software product performs useful work. Typically, the development cycle for a software product spans 1 or 2 years, while the maintenance phase spans 5 to 10 years. Estimates of the magnitude of software maintenance costs range from 50 to 75% of overall software life cycle costs. In 1985 it was estimated that software maintenance typically requires 40 to 60% of the total life cycle effort. And a widely used rule of thumb for the distribution of maintenance activities is 60% for enhancements, 20% for adaptation and 20% for error correction.

Factors Influencing Maintenance Costs

Boehm stated that for each dollar spent on software development, another dollar needs to be budgeted just to keep the software viable over its life cycle and another dollar can be spent on desirable enhancements over the life cycle.

Boehm's and Nippon's Software Productivity Range Figures shows that the most important maintenance cost driver is personnel. Maintenance work is generally perceived to be less interesting, resulting in higher personnel turnover rates than new system development work. Demotivated personnel can have a huge adverse impact on a project's cost/schedule compliance.

The maintainability of software is a qualitative measure of the following factors:

  • Ease of understanding that is reflected by the ability of an outside auditor to understand the structure, interfaces, functions and internal procedure of the software. Modularity, detailed design documentation, internal source code documentation and structured design all contribute to ease of understanding.
  • Ease of diagnosis and testing depend upon ease of understanding and again good documentation is essential.
  • Ease of change that is directly related to design criteria.

High-quality products require less maintenance and enhance both development and maintenance productivity. Investment in software reliability and modern programming practices for software development have a strong payoff during maintenance.

Software development cost models are typically ineffective in their ability to project resources for software maintenance activities for two fundamental reasons. First and foremost, they use delivered effective SLOC as the independent variable in the algorithms used to predict effort and/or schedule. The second reason is because most models define software maintenance to be only repairing errors in the code and do not include adaptive or perfective activities. (See Table 19-2.)

A lack of attention to software maintainability during the requirements specification, design, and coding phases generally leads to excessive software maintenance costs. Software changes occur not only as a consequence of detecting and correcting errors not discovered during development, but also as a consequence of postponing development tasks until the maintenance phase. This can be caused by tight schedules and as a consequence of changing system requirements. Figure 19-9, from NASA’s Handbook, indicates the relative impact of the penalty (cost) for delayed error correction during a software project’s life cycle, from almost no cost during preliminary design to high cost impacts during validation and operative stages. Business process re-engineering focuses on the later stages (maintenance) and the reduction of errors at those times by re-engineering the early phases.

 

Figure 19-9. Impact of Delayed Software Errors Detection

image

A study referred to in the SSCAG Handbook using data from 346 large electronics manufacturing firms’ programs showed that the occurrence of software bugs was strongly related to measures of size and complexity and less strongly to the program’s usage. These findings appear to vindicate those who advocate limiting program module size in order to help reduce delivered bugs. Repairing a defect has a significant (20% to 50%) chance of introducing another defect. So the entire process can be thought of as "two steps forward and one step back".

Software Maintenance Conclusions

The following suggestions are ways of improving the three types of maintenance:

  • Corrective maintenance: use of high-level languages, keep modules small, and use structured techniques,
  • Adaptive maintenance: use a portable high-level language and strive for hardware independence, and
  • Perfective maintenance: only improve modules that have a high usage level, have a reasonable life span and have a high cost for corrective or adaptive maintenance.

Programmers should be directed to develop reusable code. Although this may increase development costs, it will reduce maintenance costs, as reusable code is easier to maintain, partly because it is of higher quality and partly because there is less of it.

Structure of the software, the quality of available documentation, the experience and application knowledge of maintenance programmers, the extent and types of maintenance, and the management attitude, should be considered in estimating the maintainability of software.