Page 201 -

172 PART TWO MANAGING SOFTWARE PROJECTS

This implies that, by extending the end-date six months, we can reduce the number
of people from eight to four! The validity of such results is open to debate, but the
implication is clear: Benefit can be gained by using fewer people over a somewhat
longer time span to accomplish the same objective.

7.2.3 Effort Distribution
Each of the software project estimation techniques discussed in Chapter 5 leads to
estimates of work units (e.g., person-months) required to complete software devel-
? How much opment. A recommended distribution of effort across the definition and development
effort should
7
be expended on phases is often referred to as the 40–20–40 rule. Forty percent of all effort is allocated
each of the major to front-end analysis and design. A similar percentage is applied to back-end testing.
software You can correctly infer that coding (20 percent of effort) is de-emphasized.
engineering This effort distribution should be used as a guideline only. The characteristics of
tasks? each project must dictate the distribution of effort. Work expended on project plan-
ning rarely accounts for more than 2–3 percent of effort, unless the plan commits an
organization to large expenditures with high risk. Requirements analysis may com-
prise 10–25 percent of project effort. Effort expended on analysis or prototyping should
increase in direct proportion with project size and complexity. A range of 20 to 25
percent of effort is normally applied to software design. Time expended for design
review and subsequent iteration must also be considered.
Because of the effort applied to software design, code should follow with relatively
little difficulty. A range of 15–20 percent of overall effort can be achieved. Testing and
subsequent debugging can account for 30–40 percent of software development effort.
The criticality of the software often dictates the amount of testing that is required. If
software is human rated (i.e., software failure can result in loss of life), even higher
percentages are typical.

7.3 DEFINING A TASK SET FOR THE SOFTWARE PROJECT

A number of different process models were described in Chapter 2. These models
offer different paradigms for software development. Regardless of whether a soft-
ware team chooses a linear sequential paradigm, an iterative paradigm, an evolu-
tionary paradigm, a concurrent paradigm or some permutation, the process model
is populated by a set of tasks that enable a software team to define, develop, and ulti-
mately support computer software.
No single set of tasks is appropriate for all projects. The set of tasks that would be
appropriate for a large, complex system would likely be perceived as overkill for a
small, relatively simple software product. Therefore, an effective software process

7 Today, more than 40 percent of all project effort is often recommended for analysis and design
tasks for large software development projects. Hence, the name 40–20–40 no longer applies in a
strict sense.