The Common Process Framework for OO

20.4.1 The Common Process Framework for OO

A common process framework defines an organization’s approach to software engi- neering. It identifies the paradigm that is applied to build and maintain software and the tasks, milestones, and deliverables that will be required. It establishes the degree of rigor with which different kinds of projects will be approached. The CPF is always adaptable so it can meet the individual needs of a project team. This is its single most important characteristic.

As we noted earlier in this chapter, object-oriented software engineering applies The common process

XRef

a process model that encourages iterative development. That is, OO software evolves framework defines basic software

through a number of cycles. The common process framework that is used to man- engineering activities.

age an OO project must be evolutionary in nature. It is described in

Ed Berard [BER93] and Grady Booch [BOO91] among others suggest the use of a Chapter 2.

“recursive/parallel model” for object-oriented software development. In essence the recursive/parallel model works in the following way:

• Do enough analysis to isolate major problem classes and connections. • Do a little design to determine whether the classes and connections can

be implemented in a practical way.

CHAPTER 20

OBJECT-ORIENTED CONCEPTS AND PRINCIPLES

• ? Extract reusable objects from a library to build a rough prototype.

How do we

apply a

• Conduct some tests to uncover errors in the prototype.

recursive/parallel model for OO

• Get customer feedback on the prototype.

software

• Modify the analysis model based on what you’ve learned from the prototype,

engineering?

from doing design, and from customer feedback. • Refine the design to accommodate your changes. • Code special objects (that are not available from the library). • Assemble a new prototype using objects from the library and the new objects

you’ve created. • Conduct some tests to uncover errors in the prototype. • Get customer feedback on the prototype.

This approach continues until the prototype evolves into a production application. The recursive/parallel model is quite similar to the spiral or evolutionary para- digm. Progress occurs iteratively. What makes the recursive/parallel model different is (1) the recognition that analysis and design modeling for OO systems cannot be accomplished at an even level of abstraction and (2) analysis and design can be applied to independent system components concurrently. Berard [BER93] describes the model in the following manner:

• Systematically decompose the problem into highly independent components. • Reapply the decomposition process to each of the independent components

to decompose each further (the recursive part). • Conduct this reapplication of decomposition concurrently on all components

(the parallel part). • Continue this process until completion criteria are attained.

It’s important to note that this decomposition process is discontinued if the ana- lyst/designer recognizes that the component or subcomponent required is available in a reuse library.

To control the recursive/parallel process framework, the project manager must In many ways, the

recognize that progress is planned and measured incrementally. That is, project tasks architecture of an OO

and the project schedule are tied to each of the “highly independent components,” system makes it easier

to initiate work in

and progress is measured for each of these components individually.

parallel. However, be Each iteration of the recursive/parallel process requires planning, engineering certain that each

(analysis, design, class extraction, prototyping, and testing), and evaluation activi- parallel task is defined

ties (Figure 20.11). During planning, activities associated with each of the indepen- so that progress can

be assessed. dent program components are planned and scheduled. (Note: With each iteration, the schedule is adjusted to accommodate changes associated with the preceding iter- ation.) During early stages of engineering, analysis and design occur iteratively. The

Planning Analysis Design

Review and refinement

Early analysis/design iterations

Analysis Design

Analysis

Design

Review and refinement

Extract

Planning Analysis

Customer First

classes

evaluation prototype

Review and refinement

Extract

Planning Analysis

Customer Next

classes

evaluation increment

Review and refinement

Customer nth

reusable

classes

evaluation increment

F I G U R E 20.11 Typical process sequence for an OO project

intent is to isolate all important elements of the OO analysis and design models. As engineering work proceeds, incremental versions of the software are produced. Dur- ing evaluation, reviews, customer evaluation, and testing are performed for each increment, with feedback affecting the next planning activity and subsequent incre- ment.