Page 69 -

40 PART ONE THE PRODUCT AND THE PROCESS

anchor point and represents a set of objectives associated with the preparation of the
software for installation/distribution, site preparation prior to installation, and assis-
tance required by all parties that will use or support the software.

2.7.4 The Concurrent Development Model
The concurrent development model, sometimes called concurrent engineering, has
been described in the following manner by Davis and Sitaram [DAV94]:
Project managers who track project status in terms of the major phases [of the classic life
cycle] have no idea of the status of their projects. These are examples of trying to track
extremely complex sets of activities using overly simple models. Note that although . . . [a
large] project is in the coding phase, there are personnel on the project involved in activities
typically associated with many phases of development simultaneously. For example,
. . . personnel are writing requirements, designing, coding, testing, and integration testing
[all at the same time]. Software engineering process models by Humphrey and Kellner
[[HUM89], [KEL89]] have shown the concurrency that exists for activities occurring during
any one phase. Kellner's more recent work [KEL91] uses statecharts [a notation that repre-
sents the states of a process] to represent the concurrent relationship existent among activ-
ities associated with a specific event (e.g., a requirements change during late development),
but fails to capture the richness of concurrency that exists across all software development
and management activities in the project. . . . Most software development process models
are driven by time; the later it is, the later in the development process you are. [A concur-
rent process model] is driven by user needs, management decisions, and review results.
The concurrent process model can be represented schematically as a series of major
technical activities, tasks, and their associated states. For example, the engineering
activity defined for the spiral model (Section 2.7.2) is accomplished by invoking the
following tasks: prototyping and/or analysis modeling, requirements specification,
and design. 9
Figure 2.10 provides a schematic representation of one activity with the concur-
rent process model. The activity—analysis—may be in any one of the states 10 noted
at any given time. Similarly, other activities (e.g., design or customer communica-
tion) can be represented in an analogous manner. All activities exist concurrently but
reside in different states. For example, early in a project the customer communication
activity (not shown in the figure) has completed its first iteration and exists in the
awaiting changes state. The analysis activity (which existed in the none state while
initial customer communication was completed) now makes a transition into the
under development state. If, however, the customer indicates that changes in
requirements must be made, the analysis activity moves from the under develop-
ment state into the awaiting changes state.
The concurrent process model defines a series of events that will trigger transi-
tions from state to state for each of the software engineering activities. For example,

9 It should be noted that analysis and design are complex tasks that require substantial discussion.
Parts Three and Four of this book consider these topics in detail.
10 A state is some externally observable mode of behavior.