5.2 Kind of Software Being Developed

After project size, the kind of software you're developing is the next biggest influence on the estimate. If you're working on life-critical software, you can expect your project to require far more effort than a similarly sized business-systems project. Table 5-2 shows examples of lines of code per staff month for projects of different kinds.

Table 5-2: Productivity Rates for Common Project Types
	LOC/Staff Month Low-High (Nominal)
Kind of Software	10,000-LOC Project	100,000-LOC Project	250,000-LOC Project
Avionics	100–1,000 (200)	20–300 (50)	20–200 (40)
Business Systems	800–18,000 (3,000)	200–7,000 (600)	100–5,000 (500)
Command and Control	200–3,000 (500)	50–600 (100)	40–500 (80)
Embedded Systems	100–2,000 (300)	30–500 (70)	20–400 (60)
Internet Systems (public)	600–10,000 (1,500)	100–2,000 (300)	100–1,500 (200)
Intranet Systems (internal)	1,500–18,000 (4,000)	300–7,000 (800)	200–5,000 (600)
Microcode	100–800 (200)	20–200 (40)	20–100 (30)
Process Control	500–5,000 (1,000)	100–1,000 (300)	80–900 (200)
Real-Time	100–1,500 (200)	20–300 (50)	20–300 (40)
Scientific Systems/Engineering Research	500–7,500 (1,000)	100–1,500 (300)	80–1,000 (200)
Shrink wrap/Packaged Software	400–5,000 (1,000)	100–1,000 (200)	70–800 (200)
Systems Software/Drivers	200–5,000 (600)	50–1,000 (100)	40–800 (90)
Telecommunications	200–3,000 (600)	50–600 (100)	40–500 (90)
Source: Adapted and extended from Measures for Excellence (Putnam and Meyers 1992), Industrial Strength Software (Putnam and Meyers 1997), and Five Core Metrics (Putnam and Meyers 2003).

As you can see from the table, a team developing an intranet system for internal use might generate code 10 to 20 times faster than a team working on an avionics project, real-time project, or embedded systems project. The table also again illustrates the diseconomy of scale: projects of 100,000 LOC generate code far less efficiently than 10,000-LOC projects. Projects of 250,000 LOC generate code even less efficiently.

You can account for the industry in which you're working in one of three ways:

Use the results from Table 5-2 as a starting point. If you do that, notice that the ranges in the table are large—typically a factor of 10 difference between the high and the low ends of the ranges.
Use an estimating model such as Cocomo II, and adjust the estimating parameters to match the kind of software you develop. If you do that, remember the cautions from Chapter 4, "Where Does Estimation Error Come From?" about using too many control knobs on your estimates.
Use historical data from your own organization, which will automatically incorporate the development factors specific to the industry you work in. This is by far the best approach, and we'll discuss the use of historical data in more detail in Chapter 8, "Calibration and Historical Data."

Tip #28

Factor the kind of software you develop into your estimate. The kind of software you're developing is the second-most significant contributor to project effort and schedule.