Nextgeneration Cost Models

Software experts hold widely varying opinions about software economics and its manifestation in software cost estimation models: Source lines of code versus function points. Economy of scale versus diseconomy of scale. Productivity measures versus quality measures. Java versus C++. Object-oriented versus functionally oriented. Commercial components versus custom development. All these topics represent industry debates surrounded by high levels of rhetoric. The passionate overhype or underhype, depending on your perspective, makes it difficult to separate facts from exaggeration. Energetic disagreement is an indicator of an industry in flux, in which many competing technologies and techniques are maturing rapidly. One of the results, however, is a continuing inability to predict with precision the resources required for a given software endeavor. Accurate estimates are possible today, although honest estimates are imprecise. It will be difficult to improve empirical estimation models while the project data going into these models are noisy and highly uncorrelated, and are based on differing process and technology foundations.

Some of today's popular software cost models are not well matched to an iterative software process focused on an architecture-first approach. Despite many advances by some vendors of software cost estimation tools in expanding their repertoire of up-to-date project experience data, many cost estimators are still using a conventional process experience base to estimate a modern project profile. This section provides my perspective on how a software cost model should be structured to best support the estimation of a modern software process. There are cost models and techniques in the industry that can support subsets of this approach. My software cost model is all theory; I have no empirical evidence to demonstrate that this approach will be more accurate than today's cost models. Even though most of the methods and technology necessary for a modern management process are available today, there are not enough relevant, completed projects to back up my assertions with objective evidence.

A next-generation software cost model should explicitly separate architectural engineering from application production, just as an architecture-first process does. The cost of designing, producing, testing, and maintaining the architecture baseline is a function of scale, quality, technology, process, and team skill. There should still be some diseconomy of scale (exponent greater than 1.0) in the architecture cost model because it is inherently driven by research and development-oriented concerns. When an organization achieves a stable architecture, the production costs should be an exponential function of size, quality, and complexity, with a much more stable range of process and personnel influence. The production stage cost model should reflect an economy of scale (exponent less than 1.0) similar to that of conventional economic models for bulk production of commodities. Figure 16-1 summarizes an hypothesized cost model for an architecture-first development process.

Next-generation software cost models should estimate large-scale architectures with economy of scale. This implies that the process exponent during the production stage will be less than 1.0. My reasoning is that the larger the system, the more opportunity there is to exploit automation and to reuse common processes, components, and architectures.

16.1 next-generation cost models 239

Effort = F(TArch>

Time = F(PArch, EffortArch) + F(PApp, EffortApp)

where:

T = technology parameter (environment automation support) S = scale parameter (such as use cases, function points, source lines of code) Q= quality parameter (such as portability, reliability, performance) P = process parameter (such as maturity, domain experience)

Engineering Stage

Production Stage

Risk resolution, low-fidelity plan Schedule/technology-driven Risk sharing contracts/funding

N-month design phase

Effort.

Arch

Size/Complexity

Team Size

Architecture: small team of software engineers Applications: small team of domain engineers Small and expert as possible

Product

Executable architecture Production plans Requirements

Focus

Design and integration Host development environment

Phases

Inception and elaboration

Figure 16-1. Next-generation cost models

Low-risk, high-fidelity plan Cost-driven

Fixed-price contracts/funding

M-month production increments

Effort.

PAPP<

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment