Making Software

Using What We Can Learn from Cost-to-Fix Data About the Value of Architecting

It is useful first of all to isolate architecting as a set of early concurrent system and project definition activities and determine the effect of its use to reduce later rework and consequent project costs. We show how to tie architecting to costs in this section, and then proceed in later parts of the chapter to come up with some figures about when to do architecting and how much to do on various types of projects.

The Foundations of the COCOMO II Architecture and Risk Resolution (RESL) Factor

This chapter is based on decades of research that my colleagues and I invested in two generations of developing a Constructive Cost Model (COCOMO) for estimating software costs and project duration. By incorporating estimations of risk into this model, we succeeded in showing the value of architecting and (as will be shown later in this chapter) how much is enough.

Economies and diseconomies of scale

Our original COCOMO [Boehm 1981] did not include a factor measuring thoroughness of architecting. We did not consider whether projects have any control over the diseconomies of scale that many projects and teams suffer from.

What are diseconomies (and economies, for that matter) of scale? These are economic terms that relate the number of units of something produced to their cost per unit. An economy of scale is achieved when producing more units leads to a lower cost per unit. A diseconomy of scale is the opposite: when ...