PROCESS

The generic phases that characterize the software process—definition, development,

and support—are applicable to all software. The problem is to select the process

model that is appropriate for the software to be engineered by a project team. In Chapter

2, a wide array of software engineering paradigms were discussed:

• the linear sequential model

• the prototyping model

• the RAD model

• the incremental model

• the spiral model

• the WINWIN spiral model

• the component-based development model

• the concurrent development model

• the formal methods model

• the fourth generation techniques model

The project manager must decide which process model is most appropriate for (1)

the customers who have requested the product and the people who will do the work,(2) the characteristics of the product itself, and (3) the project environment in which

the software team works. When a process model has been selected, the team then

defines a preliminary project plan based on the set of common process framework

activities. Once the preliminary plan is established, process decomposition begins.

That is, a complete plan, reflecting the work tasks required to populate the framework

activities must be created. 

Melding the Product and the Process

Project planning begins with the melding of the product and the process. Each function

to be engineered by the software team must pass through the set of framework

activities that have been defined for a software organization. Assume that the organization

has adopted the following set of framework activities (Chapter 2):

• Customer communication—tasks required to establish effective requirements

elicitation between developer and customer.

• Planning—tasks required to define resources, timelines, and other projectrelated

information.

• Risk analysis—tasks required to assess both technical and management risks.

• Engineering—tasks required to build one or more representations of the

application.

• Construction and release—tasks required to construct, test, install, and provide

user support (e.g., documentation and training).

• Customer evaluation—tasks required to obtain customer feedback based on

evaluation of the software representations created during the engineering

activity and implemented during the construction activity.

The team members who work on a product function will apply each of the framework

activities to it.Each major product function (the figure notes functions for the word-processing

software discussed earlier) is listed in the left-hand column. Framework

activities are listed in the top row. Software engineering work tasks (for each framework

activity) would be entered in the following row.5 The job of the project manager

(and other team members) is to estimate resource requirements for each matrix

cell, start and end dates for the tasks associated with each cell, and work products

to be produced as a consequence of each task.

Process Decomposition

A software team should have a significant degree of flexibility in choosing the software

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 requirements,

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)

is adapted to it. In every case, the CPF discussed earlier in this chapter—customer

communication, planning, risk analysis, engineering, construction and release, customer

evaluation—can be fitted to the paradigm. It will work for linear models, for

iterative and incremental models, for evolutionary models, and even for concurrent

or component assembly models. The CPF is invariant and serves as the basis for all

software work performed by a software organization.

following work tasks for the customer communication

activity:

1. Develop list of clarification issues.

2. Meet with customer to address clarification issues.

3. Jointly develop a statement of scope.

4. Review the statement of scope with all concerned.

5. Modify the statement of scope as required.

These events might occur over a period of less than 48 hours. They represent a process

decomposition that is appropriate for the small, relatively simple project.

Now, we consider a more complex project, which has a broader scope and more

significant business impact. Such a project might require the following work tasks for

the customer communication activity:

1. Review the customer request.

2. Plan and schedule a formal, facilitated meeting with the customer.

3. Conduct research to specify the proposed solution and existing approaches.

4. Prepare a “working document” and an agenda for the formal meeting.

5. Conduct the meeting.

6. Jointly develop mini-specs that reflect data, function, and behavioral features

of the software.

7. Review each mini-spec for correctness, consistency, and lack of ambiguity.

8. Assemble the mini-specs into a scoping document.

9. Review the scoping document with all concerned.

10. Modify the scoping document as required.

Both projects perform the framework activity that we call “customer communication,”

but the first project team performed half as many software engineering work

tasks as the second.