SOFTWARE MODELS-6

CONCURRENT DEVELOPMENT MODELS



The concurrent development model, sometimes called concurrent engineering, hasbeen described in the following manner by Davis and Sitaram:
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 pha
ses of development simultaneously. For example,
. . . personnel are writing requirements, designing, coding, testing, and integration testing
[all at the same time]. 
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  is accomplished by invoking the
following tasks: prototyping and/or analysis modeling, requirements specification,
and design.

Figure  provides a schematic representation of one activity with the concurrent
process model. The activity—analysis—may be in any one of the states10 noted
at any given time. Similarly, other activities (e.g., design or customer communication)
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 development
state into the awaiting changes state.
The concurrent process model defines a series of events that will trigger transitions
from state to state for each of the software engineering activities. For example,during early stages of design, an inconsistency in the analysis model is uncovered.This generates the event analysis model correction which will trigger the analysis activity
from the done state into the awaiting changes state.
The concurrent process model is often used as the paradigm for the development
of client/server11 applications . A client/server system is composed
of a set of functional components. When applied to client/server, the
concurrent process model defines activities in two dimensions: a system
dimension and a component dimension. System level issues are addressed using
three activities: design, assembly, and use. The component dimension is addressed
with two activities: design and realization. Concurrency is achieved in two ways:
(1) system and component activities occur simultaneously and can be modeled
using the state-oriented approach described previously; (2) a typical client/server
application is implemented with many components, each of which can be designed
and realized concurrently.
In reality, the concurrent process model is applicable to all types of software development
and provides an accurate picture of the current state of a project. Rather than confining software engineering activities to a sequence of events, it defines a network
of activities. Each activity on the network exists simultaneously with other activities.
Events generated within a given activity or at some other place in the activity
network trigger transitions among the states of an activity.