Page 99 -

70 PART TWO MANAGING SOFTWARE PROJECTS

FIGURE 3.2
Melding the
Problem and Common process Customer Risk
the Process framework activities communication Planning analysis Engineering

Software engineering tasks
Product functions
Text input
Editing and formatting
Automatic copy edit
Page layout capability
Automatic indexing and TOC
File management
Document production

3.4.2 Process Decomposition

A software team should have a significant degree of flexibility in choosing the soft-
ware engineering paradigm that is best for the project and the software engineering
tasks that populate the process model once it is chosen. A relatively small project
that is similar to past efforts might be best accomplished using the linear sequential
approach. If very tight time constraints are imposed and the problem can be heavily
compartmentalized, the RAD model is probably the right option. If the deadline is so
tight that full functionality cannot reasonably be delivered, an incremental strategy
might be best. Similarly, projects with other characteristics (e.g., uncertain require-
ments, breakthrough technology, difficult customers, significant reuse potential) will
lead to the selection of other process models. 6
Once the process model has been chosen, the common process framework (CPF)
Always apply the CPF, is adapted to it. In every case, the CPF discussed earlier in this chapter—customer
regardless of project communication, planning, risk analysis, engineering, construction and release, cus-
size, criticality, or type. tomer evaluation—can be fitted to the paradigm. It will work for linear models, for
Work tasks may vary, iterative and incremental models, for evolutionary models, and even for concurrent
but the CPF does not.
or component assembly models. The CPF is invariant and serves as the basis for all
software work performed by a software organization.
But actual work tasks do vary. Process decomposition commences when the proj-
ect manager asks, “How do we accomplish this CPF activity?” For example, a small,

6 Recall that project characteristics also have a strong bearing on the structure of the team that is
to do the work. See Section 3.2.3.