21.1 Estimating Activity Breakdown on a Project
21.1 Estimating Activity Breakdown on a Project
One important planning decision is how much effort to allocate to the activities of requirements, architecture, construction, system test, and management. This choice will need to be made regardless of whether the project is sequential or iterative. In other words, the issue is not how much time to allocate to phases, it is how much effort to allocate to activities, whenever they will be performed.
Estimating Allocation of Effort to Different Technical Activities
Please note that the rolled-up (undecomposed) effort estimate described in Chapter 19, "Special Issues in Estimating Effort," beginning in Section 19.2, "Computing Effort from Size," forms the basis for the activity allocations made in this section.
Table 21-1 lists the percentages of the total effort estimate that you would allocate to the basic activities of architecture, construction, and system test. (KLOC stands for "1,000 lines of code.") Because of the diseconomy of scale described in Chapter 5, "Estimate Influences," the proportion of effort allocated to each activity depends on the size of the project. Requirements and management work are usually treated as special cases and are discussed later.
| Activity | |||
|---|---|---|---|
| Size | Architecture | Construction | System Test |
| 1 KLOC | 11% | 70% | 19% |
| 25 KLOC | 16% | 57% | 27% |
| 125 KLOC | 18% | 53% | 29% |
| 500 KLOC | 19% | 44% | 37% |
| Sources: Albrecht 1979; Boehm 1981; Glass 1982; Boehm, Gray, and Seewaldt 1984; Boddie 1987; Card 1987; Grady 1987; McGarry, Waligora, and McDermott 1989; Putnam and Myers 1992; Brooks 1995; Jones 1998; Jones 2000; Boehm et al, 2000; Putnam and Myers 2003; Boehm and Turner 2004; Stutzke 2005. | |||
The entries listed in Table 21-1 are approximate. They depend on the specific technical practices you use, the life-cycle model you use, effectiveness of your quality assurance work, and many other factors. Ultimately, you should develop your own table based on your organization's historical data. Until you've done that, you can use Table 21-1 as a starting point and then use the factors presented in Table 21-5 to adjust your estimate for the specific type of project you're estimating.
Estimating Requirements Effort
Table 21-1 does not include effort allocated to requirements. If you created your effort estimate using industry-average productivity data, that data is normally assumed not to include requirements activity. (That isn't always true, which is one reason that industry-average data varies as much as it does.)
If you create your estimate using your own historical data, your estimate might or might not include requirements data, depending on whether the historical data you use contains requirements data.
Estimation models, including Cocomo II and the Putnam model, assume that the rolled-up, "main build" estimates they produce do not include requirements work. One reason is that the percentage of requirements effort varies more than the percentages of the other activities do. You can quickly rush through requirements, defining a large requirements set only very loosely, which will then require Herculean effort to implement. Or you can invest more time and define a smaller set of high-quality requirements, which will allow a lower effort implementation.
With these caveats in mind, Table 21-2 lists the approximate proportion of effort you should plan for requirements work on projects of different sizes. You would add the percentage of effort from the table to your base effort estimate to compute total technical effort, including requirements work.
| Size | Amount to Add to Base Effort |
|---|---|
| 1 KLOC | 5% |
| 25 KLOC | 5% |
| 125 KLOC | 8% |
| 500 KLOC | 10% |
| Sources: same as for Table 21-1. | |
Estimating Management Effort
As with requirements effort, the rolled-up effort estimate won't include management effort unless you're using your own historical data and your historical data includes management effort. Table 21-3 lists approximate management effort for projects of different sizes. As with the requirements effort, you add the percentage of effort from the table, including management work, to your base effort estimate to compute total technical effort.
| Size | Amount to Add to Base Effort from Table 21-1 (Not Including Requirements Effort) |
|---|---|
| 1 KLOC | 10% |
| 25 KLOC | 12% |
| 125 KLOC | 14% |
| 500 KLOC | 17% |
| Sources: same as for Table 21-1. | |
Estimating Total Activity
For ease of computation, Table 21-4 lists the effort to allocate to requirements, architecture, construction, system test, and management for projects of different sizes. This table is useful when the data you use to calibrate your rolled-up effort estimate includes both requirements and management effort.
| Activity | |||||
|---|---|---|---|---|---|
| Size | Requirements | Architecture and Planning | Construction | System Test | Management |
| 1 KLOC | 4% | 10% | 61% | 16% | 9% |
| 25 KLOC | 4% | 14% | 49% | 23% | 10% |
| 125 KLOC | 7% | 15% | 44% | 23% | 11% |
| 500 KLOC | 8% | 15% | 35% | 29% | 13% |
| Sources: same as for Table 21-1. | |||||
Adjustments Due to Project Type
As Chapter 5 discussed, the type of project influences the total effort on a project. It also influences the percentage of effort that will be allocated to different kinds of activities. Table 21-5 lists the adjustments you should make to your nominal activity-percentage estimate based on the kind of project you're working on.
| Activity | Business Systems, Internal Intranet Systems | Embedded Systems, Telecommunications, Device Drivers, Systems Software | Shrink-Wrap, Scientific Systems, Engineering Systems, Public Internet Systems |
|---|---|---|---|
| Requirements | -3% | +20% | -20% |
| Architecture | -7% | +10% | -5% |
| Construction | +5% | -10% | +2% |
| System Test | -7% | +6% | +9% |
| Management | +3% | +3% | -15% |
| Sources: Putnam and Myers 1992; Jones 1998; Jones 2000; Boehm et al, 2000; Putnam and Myers 2003; Boehm and Turner 2004; Stutzke 2005. | |||
| Tip #98 | When allocating project effort across different activities, consider project size, project type, and the kinds of effort contained in the calibration data used to create your initial rolled-up estimate. |
Example of Allocating Effort to Activities
Suppose you're developing a business system that you've estimated will consist of about 80,000 lines of code (1,450 function points) and will require about 80 staff months total effort. The basic technical activity breakdown from Table 21-1 provides percentages for projects of 25 KLOC and 125 KLOC. An 80-KLOC project is about halfway between those two sizes, so we'll use the average of the table's 25 KLOC and 125 KLOC entries. Based on those percentages, you'll need to allocate 17% of your effort to architecture (13.6 staff months), 55% to construction (44.0 staff months), and 28% to system test (22.4 staff months). Table 21-2 suggests that you add 6.5% for requirements work (5.2 staff months), and Table 21-3 suggests you add 13% for project management (10.4 staff months). Table 21-6 then shows how you multiply your base effort allocation by the adjustment factors for business-systems projects to compute a final effort estimate.
| Activity | Nominal Effort Allocation (Staff Months) | Business-Systems Adjustment | Final Effort Allocation (Staff Months) | Final % |
|---|---|---|---|---|
| Requirements | 5.2 | -3% | 5.0 | 4% |
| Architecture | 13.6 | -7% | 12.6 | 13% |
| Construction | 44.0 | +5% | 46.6 | 51% |
| System Test | 22.4 | -7% | 20.8 | 22% |
| Management | 10.4 | +3% | 10.7 | 10% |
| TOTAL | 95.6 | - | 95.7 | 100% |
In this example, the totals for nominal effort estimate and final effort estimate work out to 95.6 and 95.7 staff months. In these calculations, the two totals sometimes don't work out exactly the same because of rounding errors in the adjustment factors.
Recognize that these allocations of effort to phases are approximate. They represent useful starting points for planning. Once the estimates get you into the right planning ballpark, detailed planning considerations should take precedence over these initial estimates.
Developer-to-Tester Ratios
A common planning question is, "What should the ratio of developers to testers be?" Table 21-7 lists some common ratios.
| Environment | Commonly Observed Developer-to-Tester Ratios |
|---|---|
| Common business systems (internal intranet, management information systems, and so on) | 3:1 to 20:1 (often no test specialists at all) |
| Common commercial systems (public internet, shrink wrap, and so on) | 1:1 to 5:1 |
| Scientific and engineering projects | 5:1 to 20:1 (often no test specialists at all) |
| Common systems projects | 1:1 to 5:1 |
| Safety-critical systems | 5:1 to 1:2 |
| Microsoft Windows 2000 | 1:2 |
| NASA Space Shuttle Flight Control Software | 1:10 |
The data in this table is based on observations of organizations that my company and I have worked with during the past 10 years.
As you can see from the data in the table, ratios vary significantly even within specific kinds of software. This is appropriate, because the ratio that will work the best for a specific company or a specific project will depend on the development style of the project, the complexity of the specific software being tested, the ratio of legacy code to new code, the skill of the testers compared to the skill of the developers, the degree of test automation, and numerous other factors.
Ultimately, the developer-to-tester ratio is settled more by planning than by estimation—that is, it's determined more by what you think you should do than by what you predict you will do.
EAN: 2147483647
Pages: 212