process model

What is a software process model?
In contrast to software life cycle models, software process models often represent a networked
sequence of activities, objects, transformations, and events that embody strategies for
accomplishing software evolution. Such models can be used to develop more precise and
formalized descriptions of software life cycle activities. Their power emerges from their
utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational
processing.
Software process networks can be viewed as representing multiple interconnected task chains
(Kling 1982, Garg 1989). Task chains represent a non-linear sequence of actions that structure
and transform available computational objects (resources) into intermediate or finished products.
Non-linearity implies that the sequence of actions may be non-deterministic, iterative,
accommodate multiple/parallel alternatives, as well as partially ordered to account for
incremental progress. Task actions in turn can be viewed a non-linear sequences of primitive
actions which denote atomic units of computing work, such as a user's selection of a command or
menu entry using a mouse or keyboard. Winograd and others have referred to these units of
cooperative work between people and computers as "structured discourses of work" (Winograd
1986), while task chains have become popularized under the name of "workflow" (Bolcer 1998).
Task chains can be employed to characterize either prescriptive or descriptive action sequences.
Prescriptive task chains are idealized plans of what actions should be accomplished, and in what
order. For example, a task chain for the activity of object-oriented software design might include
the following task actions:
Develop an informal narrative specification of the system.
Identify the objects and their attributes.
Identify the operations on the objects.
Identify the interfaces between objects, attributes, or operations.
Implement the operations.
Clearly, this sequence of actions could entail multiple iterations and non-procedural primitive
action invocations in the course of incrementally progressing toward an object-oriented software
design.
Task chains join or split into other task chains resulting in an overall production network or web
(Kling 1982). The production web represents the "organizational production system" that
transforms raw computational, cognitive, and other organizational resources into assembled,
integrated and usable software systems. The production lattice therefore structures how a
software system is developed, used, and maintained. However, prescriptive task chains and
actions cannot be formally guaranteed to anticipate all possible circumstances or idiosyncratic
foul-ups that can emerge in the real world of software development (Bendifallah 1989, Mi 1990).
Thus, any software production web will in some way realize only an approximate or incomplete
description of software development.
Articulation work is a kind of unanticipated task that is performed when a planned task chain is
inadequate or breaks down. It is work that represents an open-ended non-deterministic sequence
of actions taken to restore progress on the disarticulated task chain, or else to shift the flow of
productive work onto some other task chain (Bendifallah 1987, Grinter 1996, Mi 1990, Mi 1996,
Scacchi and Mi 1997). Thus, descriptive task chains are employed to characterize the observed
course of events and situations that emerge when people try to follow a planned task sequence.
Articulation work in the context of software evolution includes actions people take that entail
either their accommodation to the contingent or anomalous behavior of a software system, or
negotiation with others who may be able to affect a system modification or otherwise alter
current circumstances (Bendifallah 1987, Grinter 1996, Mi 1990, Mi 1996, Scacchi and Mi
1997). This notion of articulation work has also been referred to as software process dynamism.
Traditional Software Life Cycle Models
Traditional models of software evolution have been with us since the earliest days of software
engineering. In this section, we identify four. The classic software life cycle (or "waterfall chart")
and stepwise refinement models are widely instantiated in just about all books on modern
programming practices and software engineering. The incremental release model is closely
related to industrial practices where it most often occurs. Military standards based models have
also reified certain forms of the classic life cycle model into required practice for government
contractors. Each of these four models uses coarse-grain or macroscopic characterizations when
describing software evolution. The progressive steps of software evolution are often described as
stages, such as requirements specification, preliminary design, and implementation; these usually
have little or no further characterization other than a list of attributes that the product of such a
stage should possess. Further, these models are independent of any organizational development
setting, choice of programming language, software application domain, etc. In short, the
traditional models are context-free rather than context-sensitive. But as all of these life cycle
models have been in use for some time, we refer to them as the traditional models, and
characterize each in turn.
Classic Software Life Cycle
The classic software life cycle is often represented as a simple prescriptive waterfall software
phase model, where software evolution proceeds through an orderly sequence of transitions from
one phase to the next in order (Royce 1970). Such models resemble finite state machine
descriptions of software evolution. However, these models have been perhaps most useful in
helping to structure, staff, and manage large software development projects in complex
organizational settings, which was one of the primary purposes (Royce 1970, Boehm 1976).
Alternatively, these classic models have been widely characterized as both poor descriptive and
prescriptive models of how software development "in-the-small" or "in-the-large" can or should
occur. Figure 1 provides a common view of the waterfall model for software development
attributed to Royce (1970)