Process Modeling

a r t i c l e s

Bill Cur t is , Mar( : I. Ke l lner a n d J im O v e r

P r o c e s s M o d e l i n g raditionally, the modeling of information systems has focused on analyzing data flows and transformations. This modeling accounted only for the organization's data and that portion of its processes that interacted with data. Newer uses of in-

formation technology extend computer use beyond transaction processing into commu- nication and coordination. Successfully integrating these systems into the enterprise often requires modeling even the manual organizational processes into which these systems intervene. The following are three such applications: • • • • • • • • ® • • • •

• Business process reengineering--the redesign of an organization's busi- ness processes to make them more efficient. • Coordination technology--an aid to managing dependencies among the agents within a business process, and provides automated support for the most routinized component processes. * Process-driven software development environments--an automated system for integrating the work of all soft- ware-related management and staff; it provides embedded sup- port for an orderly and defined software development process.

These three applications share a growing requirement to represent the processes through which work is accomplished. To the extent that automation is involved, process representation becomes a vital issue in redesigning work and allocating responsibilities between humans and computers. This requirement reflects the growing use of distrib- uted, networked systems to link the interacting agents responsible for executing a business process.

To establish process modeling as a unique area, researchers must identify conceptual boundaries that distinguish their work from model- ing in other areas of information science. Process modeling is distin- guished from other types of model- ing in computer science because many of the phenomena modeled must be enacted by a human rather than a machine. At least some mod- eling, however, in the area of

human-machine system integration or information systems design has this 'human-executable' attribute. Rather than focusing solely on the user's behavior at the interface or the flow and transformation of data within the system, process model- ing also focuses on interacting be- haviors among agents, regardless of whether a computer is involved in the transactions.

Much of the research on process modeling has been conducted on software development organiza- tions, since the software engi- neering community is already accustomed to formal modeling. Software process modeling, in par- ticular, explicitly focuses on phe- nomena that occur during software creation and evolution, a domain different from that usually mod- eled in human-machine integration or information systems design. Software development is a chal- lenging focus for process modeling because of the creative problem- solving involved in requirements analysis and design, and the coordi- nation of team interactions during the development of a complex in- tellectual artifact. In this article, software process modeling will be used as an example application for describing the current status of process modeling, issues for practi- cal use, and the research questions that remain ahead.

Uses for Process Models Most software organizations possess several yards of software life cycle

description, enough to wrap end- lessly around the walls of project rooms. Often these descriptions do not correspond to the processes ac- tually performed during software development or maintenance; rather, they typically represent high-level plans and do not contain the type of how-to information that would be found in a project imple- mentation handbook. This lack of fidelity between actual behavior and the organization's stated pro- cess is caused by such factors as:

• high-level prescriptive processes that are unrelated to actual project activities, • imprecise, ambiguous, incompre- hensible, or unusable descriptions of processes to be performed on the project, and • failure to update the documenta- tion as processes change.

These large-grained life-cycle descriptions depict different phases abstractly and some may describe the point at which different func- tional groups will become involved in the project. Traditionally, these representations have been consid- ered process models. However, the software process modeling commu- nity has not been satisfied with using existing life-cycle descriptions as process models, because the granularity of the process steps in- cluded is too large. These life-cycle descriptions usually focus abstractly on product engineering and fail to show many elemental process building blocks necessary for man-

COMMUNICATIONS OF THE ACM/Septernbcr 1992/Vol,35, No.9 7 S

U ~ t i C Z ~ t ]

aging and coordinat ing the project. For instance, tradit ional life-cycle descriptions might show phase- ending reviews, but not the myriad within-phase reviews that are nec- essary for developing a quality product . Fur ther , life-cycle descrip- tions are most often t reated as lin- ear sequences, where crucial attri- butes of the process such as feedback loops and i teration are not represented [4, 7].

Research on software process model ing supports a wide range of objectives [20, 33]. Five basic uses for process models, ranging from unders tand ing aids to au tomated execution support , are presented in Table 1. These categories are:

Facilitate human understanding and communication requires that a group be able to share a common repre- sentational format

Support process improvement requires a basis for def ining and analyzing processes

Support process management requires a def ined process against which ac- tual project behaviors can be com- pared

Automate process guidance requires au tomated tools for manipula t ing process descriptions

Automate execution support requires a computat ional basis for controll ing behavior within an automated envi- ronment .

The issues raised by these objec- tives range from comprehensibil i ty to enactability. Before discussing these issues we need to establish a conceptual f ramework for process modeling.

Conceptual FrameworR A model is an abstract representa- tion of reality that excludes much of the world's infinite detail. The purpose of a model is to reduce the complexity of unders tand ing or interacting with a phenomenon by eliminating the detail that does not influence its relevant behavior. Therefore , a model reveals what its creator believes is impor tant in

unders tanding or predict ing the phenomena modeled. Selecting bounds for the phenomena to be modeled depends on the uses to which the model will be put.

H u m p h r e y and Feiler [14] have presented a foundat ional lexicon on which to build a conceptual f ramework for software process model ing and definition. They de- fine a process as "a set of partially o rde red steps in tended to reach a goal." Any component of a process is a process element. A process step is "an atomic action of a process that has no externally visible substruc- ture." Determining that a process e lement is a process step depends in par t on whether any fur ther de- composit ion of the element 's struc- ture is needed to suppor t the objec- tives of the process model. In ord inary usage a task is often syn- onymous with a process and an ac- tivity is synonymous with a process e lement or step. We will, however, avoid these terms for the sake of clarity.

Al though there is not wide- spread consensus on the constructs that collectively form the essential basis of a process model, the follow- ing list includes many of those most frequently ment ioned (abstracted f rom [9, 14, 27, 35]).

Agent--an actor (human or ma- chine) who per forms a process ele- ment.

Role--a coherent set of process ele- ments to be assigned to an agent as a unit o f functional responsibility.

Artifact--a product created or mod- ified by the enactment of a process element.

A single agent can pe r fo rm mul- tiple roles (e.g., designer, reviewer, coder), and a single role (coder) may be pe r fo rmed by mult iple agents. A process can now be fur- ther e laborated as one or more agents acting in def ined roles to enact the process steps that collec- tively accomplish the goals for which the process was designed. Typically, process steps ei ther ma- nipulate an artifact or coordinate

dependencies with other agents involved in the same or a related process. Consequently, process steps should be p lanned as par t of a def ined process, assigned to a role, allocated resources, and moni- tored.

A process model is an abstract descript ion of an actual or pro- posed process that represents se- lected process elements that are considered impor tan t to the pur- pose of the model and can be en- acted by a human or machine. The levels of abstraction within the domain of software deve lopment range from the detai led process steps executed entirely on a ma- chine, to the la rger -gra ined human processes involved in executing a life-cycle phase, to the abstract stages of the life-cycle chosen for the product . Defined or not, the collection o f all the process steps executed to develop a software sys- tem constitutes a software develop- ment process. These processes, however, do not constitute a soft- ware process model until they are represented in some medium. A process model to be pe r fo rmed by a human will be called a process script, while one to be enacted by a ma- chine will be called a process program [14, 30].

Most life-cycle descriptions rep- resent an extremely abstract model o f software deve lopment and do not provide clear guidance on how to integrate the many process steps that project staff per form. One of the objectives of software process model ing is to decompose these descriptions into sufficient detail so that they can provide more explicit guidance for executing a software deve lopment project. Since many projects are managed as loose col- lections of process elements that constitute di f ferent tasks (an unin- tegra ted set of process fragments), projects might be made more effi- cient if the process elements and steps under ly ing di f ferent pro- cesses could be in tegrated into an efficient s tructure for executing the desired software deve lopment pro- cess.

~ 6 September 1992/Vol.35, No.9/COMMUNICATIONS OF THE Ai~M

a r t i c l e s

Perspect ives in Process R e p r e s e n t a t i o n Many forms of information must be integrated to adequately describe software processes. Among the forms of information that people ordinarily want to extract from a process model are what is going to be done, who is going to do it, when and where will it be done, how and why will it be done, and who is de- pendent on its being done. Process- modeling languages differ in the extent to which their constructs highlight the information that an- swers these different questions. Process-modeling languages and representations usually present one or more different perspectives re- lated to these questions. Four of the most commonly represented per- spectives are:

Functional represents what process elements are being performed, and what flows of informational entities (e.g., data, artifacts, products), are relevant to these process elements.

Behavioral represents when process elements are performed (e.g., se- quencing), as well as aspects of how they are performed through feed- back loops, iteration, complex deci- sion-making conditions, entry and exit criteria, and so forth.

Organizational represents where and by whom (which agents) in the organization process elements are performed, the physical communi- cation mechanisms used for trans- fer of entities, and the physical media and locations used for stor- ing entities.

Informational represents the infor- mational entities produced or ma- nipulated by a process; these enti- ties include data, artifacts, products (intermediate and end), and ob- jects; this perspective includes both the structure of informational enti- ties and the relationships among them.

These perspectives underlie sep- arate yet interrelated representa- tions for analyzing and presenting process information (Figure I).

T a b l e 1. S o f t w a r e Process M O d e l i n g O b j e c t i v e s a n d Goals

FACILITATE HUMAN UNDERSTANDING AND COMMUNICATION • Represent process i n f o r m understandable by h u m a n s

• Enable communication about and agreement on software processes • Formalize the process so that people can work together more effectively • Provide sufficient information to allow an individual o r t e a m t o perform the

intended process • F o r m a basis for training the intended process

SUPPORT PROCESS IMPROVEMENT • Identify all the necessary components of a high-yield software development

or maintenance process • Reuse well-defined and effective software processes on future projects • Compare alternative software processes • Estimate the impacts of potential changes to a software process without

first Putting them into actual practice • ASSISt in the selection and incorporation of technology (e.g., tools) into a

process • Facilitate organizational learning regarding effective software processes • SupPort managed evolution of a process

SUPPORT PROCESS MANAGEMENT • Develop a project-specific software process to accommodate the attributes

of a particular project, such as its product, or organizational environment • Reason about attributes of software creation or evolution • Support development Of plans for the project (forecasting) • Monitor, manage, and coordinate the process • Provide a basis for process measurement, such as definition of measurement

points within the context Of a specific process

AUTOMATED GUIDANCE IN PERFORMING PROCESS • Define an effective software development environment • Provide guidance, suggestions, and reference material to facilitate human

performance of the intended process • Retain reusable process representations In a repository

AUTOMATED EXECUTION SUPPORT • Automate portions of the process • Support cooperative work among individuals and teams by automating the

process • Automatically collect measurement data reflecting actual experience with a

process • Enforce rules to ensure process integrity

They are analogous to different vantage points from which one may view an observable process. We can hypothesize that when combined, these perspectives will produce an integrated, consistent, and com- plete model of the process ana- lyzed. This hypothesis, however, needs verification through experi- mental process modeling. Integra- tion and consistency may be easier to demonstrate, since completeness is relative to the application. Com- pleteness depends on whether all important components of informa- tion remain after less crucial details have been abstracted away by the modeling technique, and on whether the intended uses of the model are enabled by the perspec- tives offered.

In practice, most process de-

scriptions have employed narrative text and simple diagrams to express process, with the text often struc- tured in a uniform way (e.g., in- puts, outputs, activity description). Many conventional uses of process models have posed few require- ments on the formal properties of the representation, since their use was more for communication than for analysis. The perspectives that a process model is able to present are bounded by the constructs of the language (textual or graphic) used for modeling. When semantic and syntactic constraints are loosely applied to a representation, how- ever, it is easier for modelers to interleave many perspectives in a process description. Unfortunately, it is difficult to analyze the proper- ties of these perspectives when the

COMMUNICATIONS OF THE ACM/September 1992/Vol,35, No.9 7 7

representation has not been for- mally constrained.

Process Model ing Paradigms Process-modeling languages and representations can be evaluated by the extent to which they provide constructs useful for representing and reasoning about the various aspects of a process. Since software specification and programming languages provide a means for rep- resenting, reasoning about, and enacting a computational process,

Figure 1. Concept of process per- spectives

most researchers have started from this language base in modeling soft- ware processes. They often begin by proposing language structures and formalisms for modeling.

Osterweil [30] has pointed out a chicken-and-egg problem in ex- ploring representations suited to software process modeling. "In order to find out what language features we need, we need to write process programs; in order to write process programs, we need the appropriate language features." Most language classes used by the software community have been tried as a basis for modeling soft-

ware processes, and dozens of mod- eling languages derived from them have been proposed in the past sev- eral years. Table 2 identifies the language types and constructs sup- ported by several of the process- modeling languages being explored in the research community. Table 2 is not intended to be complete, merely illustrative of the variety of language types being studied. Table 3 summarizes how these lan- guage types and constructs support the four perspectives discussed in the preceding section. Comparing the profiles between these two ta- bles provides a summary analysis of

top perspective (e.g., functional)

Actual Pro( right perspective

(e.g., organizational)

left perspective (e.g., behavioral)

/ back perspective

(e.g., informational)

7 8 September 1992/Vol.35, No.9/COMMUNICATIONS OFTHE ACM

I r ~ l c l e s

how different languages used for process modeling support the four perspectives.

There have been several efforts to gain experience in developing and analyzing models of actual soft- ware processes [17, 19, 20, 23, 32, 34]. Feedback between language development and application expe- rience is necessary to successfully evolve software process-modeling techniques. Such experiments are crucial to support experience-based language design.

In order to summarize the breadth of process-modeling re- search, five approaches to repre- senting process information will be reviewed. These techniques do not cover the full range of modeling techniques developed, hut they do provide an overview of some of the most extensively explored ap- proaches. These five approaches to modeling, each described through an example technique, are:

Programming models--process pro- gramming

Functional models--HFSP Plan-based models--GRAPPLE Petri-net models--role interaction nets Quantitative models--system dynam- ics.

Programming Models In stating the case for process pro- gramming, Osterweil [30] argues that "software processes are soft- ware, too." That is, since specifying a process is a form of program- ming, processes can be modeled with all the tools and techniques of the programmer 's trade. The re- sulting programs are bound to humans as well as machines. Oster- weil maintains that people develop process descriptions to solve prob- lems. These descriptions can be modeled as algorithms and can be analyzed accordingly. Osterweil and his colleagues developed APPL/A [36] for constructing pro- cess programs that can he enacted by a machine: APPL/A [36] and p4 [10] .

The Ada Process Program- ruing Language based on Aspen (APPL/A) allows processes to be modeled in an extension of Ada that enables explicit representation of programmable, persistent rela- tions. Aspen is a data model for software engineering that incorpo- rates relations over software objects in an entity-relationship form. APPL/A adds triggers that can propagate updates across relations and provide other functions among them. Predicates have been added that express conditions on the state of relations and therefore can rep- resent constraints. Process pro- gramming has often been unfairly characterized as a purely proce- dural approach. Since it provides both procedural and declarative capabilities, APPL/A supports mul- tiple representational paradigms, an approach to process modeling that will be discussed in a later sec- tion.

Sutton et al. [37] have used APPL/A to implement a tool - - REBUS-- tha t supports the process

11:ble 2. Language Types and Constructs Used as Bases f o r S o f t w a r e Process M o d e l i n g

Base Language Types Sample SOftware PrOCeSS and Constructs Modeling Approaches

Procedural programming languages

Systems analysis and design 1

AI languages and approaches 2

Events and triggers

APPL/A [361

STATEMATE [20]

AP5 [40], GRAPPLE [12], MARVEL [17], MVP [34]

AP5 [40], APPL/A [36], STATEMATE [20]

State transition and petri-nets Role Interaction Nets [35], STATEMATE [20]

Control flow MVP [34]

Functional languages

Formal languages

HFSP [38]

Context-Free Grammar

Data modeling 3 APPL/A [36], PMDB [32[, STATEMATE [201

Object modeling 4 AP5 [40], MARVEL [17], MVP [34]

Precedence networks 5 SPMS [this issue]

Quantitative modeling System Dynamics [1]

1--including DFD, SADT, structure charts 2--including ru~es pre-/post-conditions 3--including E/R, relations, structured data declarations 4--including class types and instances, hierarchy, inheritance 5--including PERT and critica~ path method (CPM)

COMMUNICATIONS OF THE ACM/September 1992/Vol.35, No.9 1 t

I l r t i c l e s

of developing requirements. REBUS helps analysts manage the process of mutually developing the data structures in which to express the statement of requirements. Experience with REBUS indicated that process programming could successfully automate some of the routine aspects of controlling inter- action in the shared requirements workspace that otherwise burdened the analysts with unnecessary pro- cess steps. The formality enforced in REBUS emanated from the for- mal structure of the requirements document, rather than from the structure of the process. Thus, while individual methods for per- forming activities and tasks were not controlled, the emerging struc- ture of the artifact and the group interaction process for producing it were controlled. Although small- grained concurrency control was provided, a need surfaced for a larger-grained version that was not supported in APPL/A. The model- ing performed with languages such as APPL/A is very procedural, and leads to control models that would

underlie a conventional software development environment. Even initial prototypes, such as REBUS, quickly surface the need for capa- bilities that will be crucial in scaling up automated process models to support process-based environ- ments.

Funct iona l Models The Hierarchical and Functional Software Process (HFSP) descrip- tion and enaction language was developed at the Tokyo Institute of Technology by Katayama and his colleagues [38]. The key goals of HFSP are t o :

• aid process understanding • support hierarchical process de- composition • describe concurrent processes and backtracking • provide a flexible and dynamic execution mechanism

HFSP is primarily a declarative, textual language; but execution traces can be illustrated diagram- matically. In HFSP, a process is rep- resented as a collection of process

T a b l e 3. Perspect ives for Process In fo rmat ion and

Appl icable Language Bases

Perspectives

o t- m

o _o ~ u m (~ 1- e-

u. m O --=

Procedura l P r o g r a m m i n g languages ~ ~"

S y s t e m s ana l ys i s and design /,4

A l l a n g u a g e s a n d a p p r o a c h e s ~"

Events and triggers

state transition and petri-nets ~,2 Control f low Functional languages ~' Formal languages Data modeling Object modeling Precedence networks

;,,,2

/J'

Notes: le.g, product structure charts 2specifically role-interaction nets

elements with input and output at- tributes. Specifically, a process is defined as a set of mathematical functions depicting relationships among inputs (such as specifica- tions) and outputs (such as source codes). Furthermore, each of these functions is hierarchically decom- posable into process subelements, where the input and output attri- butes of a parent process element must be satisfied by its children's attributes. This decomposition is continued until it produces process steps that can be mapped to exter- nal tool invocation or manual oper- ations.

In general, process elements can execute concurrently, limited only by availability of input attributes. However, additional features have been incorporated into HFSP to represent special ordering infor- mation such as sequencing, itera- tion, and synchronization. In addi- tion, metaoperators have been added to permit inclusion of dy- namic control of behavior, such as creating, destroying, suspending, or resuming process elements, and communicating among them. Fi- nally, a process enaction mecha- nism would be responsible for ac- tivity-scheduling (based on such items as resource constraints, activ- ity execution management, tool invocation, object base access, and user interaction).

HFSP is primarily oriented to- ward the functional and behavioral perspectives, with some support for the informational perspective. In applying HSFP to an industrial process, Katayama and Motizuki [19] report that the organizational perspective was difficult to model because of the extent to which it was poorly documented, and often was driven by political rather than technical factors. They decided not to model transient artifacts created within the process but not perma- nently stored. They found that in practice they halted their process decomposition short of reaching process steps because of substantial variations in the way different agents performed their duties.

0 September 1992/Vol.35, No.9/COMMUNICATIONS OF THE ACM

a r e l ¢ l e s

They found it difficult to identify a priori the communication points between concurrent processes. They found that allowing a process element to execute when its input was available was an advantage in expediting progress among inter- acting agents, rather than requiring that all components of a decom- posed artifact be available before enabling performance of the next process element. Finally, they ob- served a requirement for a meta- level process to control (manage) the execution of other processes. Katayama and Motizuki concluded that in trying to model actual pro- cesses, they might discover new processing concepts for computer science.

Plan-Based Models Huff and Lesser argue that model- ing process execution in the real world is difficult because of all the contingencies that must be consid- ered [12]. This contingency man- agement poses particular problems for procedural languages because the rationale underlying the design of the process has been removed from the procedural representa- tion. The rationale is, therefore, unavailable for reasoning about enaction choices based on existing conditions within the current state of a process's execution. They pro- pose that these problems can be more effectively handled in the planning paradigm that has emerged from artificial intelligence research. This paradigm provides mechanisms whereby operators representing possible actions are selected based on the satisfaction of their preconditions. These opera- tors are applied to the current state of the domain in which the process operates, in order to move that state closer to the desired goal.

Huf f and Lesser created a con- straint-based language called GRAPPLE that models software development as a set of goals, sub- goals, preconditions, constraints, and effects. GRAPPLE constructs process models from two funda- mental components: a set of pro-

cess steps and a set of constraints on how those steps can be selected, ordered, and applied. The ability of a constraint-based planning system like GRAPPLE for developing ef- fective process plans depends on the success of its designer in coding knowledge about the environment and the goal hierarchies of the process into the components of GRAPPLE. Huf f and Lesser pro- vide a high-level example for rep- resenting a system release: Operator: release Goal: current-release

(system) Preconditions: built(system)

regression-tested (system)

performance-tested (system)

Constraints: current-release(C) not-equal(C,system)

Effects: DELETE current- release(C)

ADD current- release (system)

ADD customer- release (system)

ADD prior-release (system,C)

In this example, the computa- tional agent will seek to satisfy the goal of making 'system' the current release when a set of preconditions have been satisfied without violat- ing the stated constraints. In con- trast to procedural approaches GRAPPLE produces process plans dynamically by comparing condi- tions in the current state of the en- vironment with the preconditions of the operators available for acting on it. Plan execution can be simu- lated to reason about the viability of selecting a particular path for the plan. The status o f satisfying differ- ent goals in the goal hierarchy is tracked as a means of guiding oper- ator selection.

Experiences with GRAPPLE re- vealed that the most interesting process models resulted when the artifact operated on by the process had been represented in a way that revealed internal structure, current attributes, and external dependen- cies. These descriptive attributes o f

the artifact provided a rich source of constraints for guiding the selec- tion of operators. Huf f and Lesser also identified a need to integrate multiple sources of knowledge rep- resentation and an analysis capabil- ity for deriving the properties of processes.

Petri-Net Models One view of a project that is orthog- onal to the perspective portrayed by most programming language- based models is provided by its structure of roles and their interac- tion. Most o f the recent activity with this approach was motivated by Anatole Holt's work in applying Petri nets to modeling coordination in the workplace [11]. This work has been carried on in projects at MCC [35], and at Praxis Systems [31]. This technique models the role interaction structure of a proj- ect using a Petri-net-based repre- sentation and language.

The technique employed at MCC was derived from a Petri-net-based language called RADDLE devel- oped by Ira Forman for use in modeling high-level designs for a distributed system. Extensive modi- fications, however, had to be made to the formalism to provide the flexibility needed for the system to be used in aiding human coordina- tion. For instance, the tight concur- rency control enforced in comput- ing systems often must be relaxed (but in systematic ways) when hu- mans are the agents of execution. Extensive modeling of industrial software processes resulted in addi- tions to the model for scalability. The Petri-net-based role interac- tion model has now been used in a commercial product.

Role interaction nets are de- signed to aid the representation and execution o f structured tasks. Structured tasks are those that can be planned from known dependen- cies. One possible process for con- ducting a technical review is mod- eled in role interaction nets in Figure 2 (the figure has been sim- plified to remove the representa- tion of iteration). Role interaction

COMMUNICATIONS OF THE ACM/Septeinber 1992/Vol.35, No.9 8 1

e l F C; :: ,~ : :Z ,,'Z S;

nets are strong in representing roles, dependencies, and process elements. Its representation of arti- facts, however, is weak.

When a process has been repre- sented in role interaction nets, a new notion of teams emerges, built on dependencies among roles, rather than on reporting relation- ships. Where interactions among roles are frequent, a clustering of roles forms a de facto team. A pro- cess plan can be designed as a decomposition of tasks, roles, and interactions. A project plan is established when roles are assigned to individuals. One individual may hold many roles and a type of role may be assigned to several individ- uals.

Having instantiated a project plan, role interaction nets can be used as a method of coordinating the routing of artifacts among in- teracting roles and as a method of tracking progress by the comple- tion of interactions among :roles. That is, this formalism can be used as an underpinning for coordinat- ing activities in a process-driven environment. However, technology transfer experience suggests that this model of coordination among role structures is difficult to use if an organization has not been able to establish a basic description of their process.

Quantitative Models One of the few modeling tech- niques that involves quantitative representation is system dynamics, which applies feedback and control system techniques to social and in- dustrial phenomena. Models built using system dynamics techniques attempt to define a set of quantita- tive relationships among variables of interest that simulate the ob- served behavior of social systems.

Abdel-Hamid and Madnick have used this technique to provide a quantitative representation of many behavioral observations of software projects [1]. One of their primary objectives has been to demonstrate why managers chroni- cally underestimate the resources

required for a software project. A primary problem in estimating the schedule and resources needed for a project is that feedback loops allow a complex, dynamic system to compensate for changes at any node in the system. For instance, if management relaxes the schedule constraints on a project, then hiring is slowed, productivity drops be- cause of greater perceived schedule slack, and the project falls into the same schedule slippage problem. When these interacting factors are modeled, their effects on successive cycles can be simulated. The simu- lated behavior presents one possi- ble model of the 90%-complete syn- drome that plagues projects.

An example of a typical equation that might appear in such a model is a simulation of how a manager measures progress based on the stage of the project. During the early stages of a project, managers frequently measure progress by the percent of total project effort that has been expended to date. At the latter stages, managers measure progress by the actual percent of work that has been accomplished, such as the number of modules that have successfully passed the inte- gration test phase, or the number of problem reports closed. Thus, the perceived work accomplished was modeled as: PWA = [VF * (% resources con- sumed)] + [(1 - VF) * (actual % work finished)]

where, PWA = perceived % of work accomplished;

VF -= visibility factor, and 0-< VF-< 1; where

VF ~- 1 at project start VF = 0 at project end

When a set of equations such as this interact, they produce dynamic behavior that is difficult to repro- duce through modeling techniques that do not provide dynamic feed- back loops. The value of these models is very much tied to the closeness with which their con- structs and parameters represent actual states observed on real proj- ects.

Issues in Process Modeling Formality A primary issue in the research agenda involves the level of mathe- matical formality needed in pro- cess-modeling languages. Scaling on this dimension represents a lan- guage's level of formal precision in representing the process. A for- mally precise language is enactable on a machine. The level of formal- ity required may depend on the purpose served by the process model and the agent responsible for enacting the specified pro- cesses. That is, process programs enacted by a machine must be quite formal, whereas process scripts performed by humans may require less formality.

The strong position on formality has been taken by Osterweil in de- scribing process programming [30]. However, Lehman [25] and Curtis et al. [7] maintain that computer programming is too deterministic a paradigm for processes to be en- acted by humans. This problem has motivated the distinction between process programs and process scripts. They argue that while com- puters have precise execution se- mantics, humans do not. Osterweil indicates that many software devel- opment processes are only partially automated, involving interaction between human and computer agents. Although some languages (e.g., systems analysis and design languages) have been used to depict both automated and manual pro- cesses, many extensions of existing programming languages have only been applied to those process com- ponents being automated.

Flexibility in representing man- ual tasks performed by humans is a fundamental requirement for de- veloping process scripts [10]. Hu- mans exhibit far more variability than computers in executing a de- fined process. Nevertheless, they are able to enact ambiguous process descriptions because they can fill in gaps in these descriptions before enacting them. Expressiveness and comprehensibility are more crucial for humans, since they exhibit less

82 September 1992/Vol.35, N o . 9 / C O M M U N I C A T I O N S OF T H E A C M

a r t i c l e s

precision in parsing process in- structions. Experience shows that even those using formal specifica- tion languages often have run their specifications back th rough a trans- lator to produce a natural language version that was more unders tand- able [2].

Unfortunately, interest in facili- tating human unders tanding and communicat ion has received less attention from the research com- munity than has machine enaction. Process models and definitions can- not be used if they cannot be un- derstood. The large number of po- tential process model users, such as software process engineers, project managers, software engineers, sys- tem engineers, software executives, and customer management makes it difficult to establish a universally unders tood representat ion format. Due to their individual information needs and expertise, these groups place widely diverging demands on a model ing approach. Visual repre- sentations, abstraction, and multi- ple perspectives offer promising techniques for coping with these challenges. Even so, Curtis, Kras- ner, and Iscoe found that a homo- geneous group could spend six months developing a common un- ders tanding o f the semantics of a representat ion format [6].

A process-modeling language should permit evaluation of the adequacy of a p roposed process. The model should be analyzable for such propert ies as syntactic correct- ness, consistency, completeness, correctness, risks, and oppor tuni - ties for improvement , among oth- ers. Most formalisms and tools typi- cally p rov ide the first few types o f analysis, since they emerge from the formal propert ies of the repre- sentation. However, a representa- tion's formal propert ies can sup- por t more advanced analyses such as reachability of various process states, detection of deadlocks, and race conditions in the process, de- tection of behavioral ambiguities [20, 23]. These analyses are pro- vided by some state-transition and Petri-net-based approaches.

Kellner and Hansen observed that while it is generally not feasible to guarantee such factors as the correctness or completeness o f a model, it is possible to search for anomalies within the processes bounded by the model [23]. How- ever, if no anomalies are found, an impor tant degree of assurance has been provided that the process being modeled is internally sound.

executing agent already possesses of the contents and sequencing of process steps, the larger the grain of the process step that can be used in a process model. Tha t is, with greater process knowledge, larger- grained model ing units can be used to invoke sequences of process steps when the model is enacted by an agent.

In many domains, descriptions

Review Review Team Team

Designer Leader Member

Announce review team

E " ~ d schedule PI iew t ime-~"~ . . . .

/ ~./stribute design d . . . . . t

Receive document-~ I____J i Send review commants~

(~Collect reviews I I _ _ Schedule review meeting

~rJsem ,.es,g. i

Record minutes - '~ BIBBBI Attend and question ~ I I and action Items

. J I \-DJ strlbute mInutes ( ~ ~evlew minutes ~ Review minutes ~ Submit completed

Project Manager

Update status-"~ ( ~ Approve review team membersh~ ~

Update status~'~

Note problems--~[~

i ,, ,.~nitrm action item completion m Update status'~ ~ ]

The external validity of a process model must be de te rmined by the value of its use and the degree of fidelity it offers in depict ing rele- vant phenomena in the real world.

Granularity and Precision The granulari ty issue involves the size of the process elements repre- sented in the model. The pressure for greater granulari ty is driven by the need to ensure process precision-- the degree to which a def ined pro- cess specifies all the process steps needed to produce accurate results [14]. The granulari ty of a process step needed to ensure process pre- cision will depend on the purpose of the model and attributes o f the agent that must execute the pro- cess. The more extensive the un- ders tanding or representat ion the

F i g u r e 2. Role interaction net for re- view team

for process scripts are presented to humans at too high a level of ab- straction (large-grained) and they do not provide sufficient detail for guiding actual execution. Conse- quently, human agents are ex- pected to have sufficient knowledge to translate these imprecise scripts into actions by filling in detailed process steps that are appropr ia te to cur rent conditions. I f the human agent a l ready knows many relevant potential scripts, a large-grained process model may be desirable in o rde r to allow the agent to tailor the final detai led process script en- acted. This flexibility may be espe- cially desirable when there are com- plicated decision rules for selecting

COMMUNICATIONS OF THE ACM/September 1992/Vo1.35, No.9 8 3

and integrating the processes to be performed. If human agents do not possess sufficient process knowl- edge, it may be desirable to model finer-grained process steps with approaches that represent aherna- tive steps and sequences and can encode guidance in how to choose among them.

Current experience suggests that automated processes require a small-grained representation, while process scripts to be executed by humans can be represented in models with larger units than those used in process programs. Still, the granularity of these models is much smaller than those constituting most life-cycle descriptions. Pro- gramming-language-based ap- proaches to modeling have largely been used to represent small- grained models that supported spe- cific forms of process enactment on a machine, Techniques derived from design languages, especially those with strong visual representa- tions, are often used for larger- grained process models. Not sur- prisingly, this observation coincides with the level of abstraction nor- mally associated with the use of these languages in software engi- neering. Ultimately, process models must support multiple levels of ab- straction to serve the various needs.

Scriptiveness and Fitness Process modelers have differed on how prescriptive they intend their models to be of the actual behaviors to be performed. Prescriptive model- ing implies the process should be performed a particular way. Much of the process-modeling research presupposes the existence of a pre- scriptive process in a process mod- eler's mind, that is then translated into a modeling formalism. Pre- scriptive models must be analyzed for their processfitness--the degree to which the agents performing the process can faithfully follow the process steps it specifies [14]. When prescriptive process models violate the reasonable exercise of human or machine capabilities, process fit- ness is low.

The prescriptive approach to process modeling can be at odds with the concept of process im- provement based on continuous evolution when the prescribed pro- cess is difficult to perform (i.e., when process fitness is low [14]). The evolutionary approach begins with an understanding of the cur- rent process used in an organiza- tion. Descriptive modeling attempts to determine the actual processes cur- rently used in an organization to get work done, an organization's process baseline. Improvements are made as changes to the established process baseline, since these are likely to be the most successfully absorbed by an organization. Man- aged improvement is also based on measurements of actual perfor- mance that are related to the pro- cesses actually performed (a de- scriptive model), which may differ from those planned (a prescriptive model). More work is needed on methods for capturing descriptive process information, on integrating measurement with process repre- sentations, and on analyzing de- scriptive models for those points at which process changes can be most successfully inserted in an evolu- tionary way.

A third perspective is offered by proscriptive models, which delineate behavior that is not allowed. Law- governed modeling takes this ap- proach [29], and is used for exercis- ing control over the allowable steps that can be taken in a process. For instance, constraint-based model- ing techniques such as embodied in AP5, GRAPPLE [12], and MAR- VEL [18] allow the modeler to indi- cate constraints that cannot be vio- lated by the execution of a process. A proscriptive model might indi- cate that a modified module cannot resume its former status in the con- figuration management system until it has been regression-tested. Proscriptive modeling will most often be used as an adjunct to pre- scriptive or descriptive modeling.

Future Directions: Field Growth In order to accelerate the growth of

process modeling, seven Interna- tional Software Process Workshops have been held since 1984. These workshops annually bring together 35 researchers selected on the basis of position papers to discuss their most recent results. The proceed- ings of this workshop (published by IEEE Computer Society Press, Washington, DC) presents the best annual review of progress in the process-modeling field. The field is growing, and in 1991 the First In- ternational Conference on the Soft- ware Process attracted 200 people from both academia and industry. A review of this brief literature will indicate that currently the field is primarily focused on properties of languages for representing pro- cesses and on process-driven envi- ronments.

An important step in under- standing and comparing the vari- ous approaches to software process modeling has been undertaken in conjunction with the Sixth and Sev- enth International Software Pro- cess Workshops (ISPW). A working group has developed a benchmark software process modeling example problem [22]. The original ISPW-6 Software Process Example was care- fully designed to incorporate exam- ples of 18 important process aspects and issues focusing on representa- tion issues [24]. Additional exten- sions were developed for the Exam- ple in conjunction with ISPW-7, highlighting teamwork issues, and process change '.

At least 24 different modeling approaches have been applied to this common process example. As a result, the Example has provided an important b~isis for understand- ing, comparing, and assessing various modeling approaches. In addition, it has successfully com- m u n i c a t e d - w i t h concrete exam- pies-- the diversity of process as- pects encountered in real-world software processes. As a result, sev- eral researchers have extended and

~Copies of this problem may be obtained at cost by contacting Rocky Mountain Institute of Software Engineering (rMise), P.O. Box 3521, Boulder, CO 80303.

8 4 Segten~be~" 1992/'Mo|.35, No.9/COMMUNICATIONS OF THE ACM

a r l : l c l a s

enhanced their approaches in re- sponse to working through the Example.

Multi-Paradigm Representations The suitability of a modeling ap- proach will depend on the goals and objectives for the resulting model [24]. A given language con- struct or type will be better suited to achieving some modeling objectives than others. The goals and objec- tives outlined in Table 1 present diverse requirements for a model- ing technique that no current soft- ware process modeling approach fully satisfies. The diversity in audi- ences, in information content, and in the different descriptive capabili- ties needed for human vs. machine enaction of processes all impose broad, and sometimes conflicting, requirements on a modeling ap- proach. An approach that inte- grates multiple representational paradigms is currently considered necessary for effective software process modeling. However, the application of multi-paradigm rep- resentations raises additional chal- lenges regarding translation, com- munication, coordination, and interaction among model compo- nents.

A limited number of software process-modeling languages (e.g., APPL/A [36], MVP) are already combining at least a few language paradigms [34]. One prominent approach in this category has been developed, refined, and applied at the Software Engineering Institute (SEI) by Kellner and his colleagues [15,20, 21, 23], and is supported by a commercial CASE tool called STATEMATE. This modeling ap- proach is focused on supporting three of the objectives outlined in Table 1: facilitate human under- standing and communication, sup- port process improvement, and support process management. STATEMATE-based modeling provides a software design and analysis paradigm, formal visual languages, multiple integrated per- spectives, and powerful automated analyses and simulations.

Of the four perspectives de- scribed earlier, the STATEMATE- based approach was specifically developed to support the func- tional, behavioral, and organiza- tional perspectives; it can also pro- vide support for the informational perspective [15]. This approach supports multiple language para- digms as suggested in Table 2, in- cluding: • state transitions with events and triggers (used for the behavioral perspective), • systems analysis and design dia- grams: enhanced data flow dia- grams (used for the functional per- spective), and modified structure charts (used for the organizational perspective) • data-modeling (used with the functional perspective and addi- tional informational perspective)

A small example of a STATEMATE model for a process element developing code and tests is presented in Figure 3.

Substantial experience with this approach to software process mod- eling has been gained at the SEI in recent years, and includes major efforts at modeling large-scale soft- ware processes. The STATEMATE modeling approach has been ap- plied to model the processes in ac- tual use for supporting the opera- tional software for the F-14A [20], and F-16A/B aircraft. These two models depict the full software sup- port process from receipt of a soft- ware trouble report, change re- quest, or enhancement request, through to release of the corre- sponding software change to the field. Other applications modeled processes presented in narrative prescriptions in a military hand- book (MIL-HDBK-347). In these efforts, the work has progressed beyond simply representing the process, and has included manual and automated analyses of the pro- cess, followed by recommendations for process improvements based on those analyses. The application of appropriate existing technology has allowed the SEI team to focus their

efforts on developing the approach and the actual models, rather than on building tools.

Although a small number of lan- guage paradigms can be integrated within a single modeling approach, even more diversity may be re- quired to meet the wide-ranging objectives of modeling. A potential strategy for coping with this chal- lenge is illustrated in Figure 4. This technique is based on the loose inte- gration (incorporation) of various modeling paradigms, allowing users to capitalize on their best as- pects. The central research hypoth- esis is that a "common denominator schema" can be defined and evolved that will contain the union of all vital process information han- dled by the various representations. The common denominator schema would be in a basic representational form, such as an object-oriented, entity relationship, or relational schema, and thus would not be suit- able for direct user manipulation. However, automatic translators could extract the subset of informa- tion represented by a given model- ing approach, and store it in an ob- ject-base (database) defined by the common denominator schema. Similarly, various additional projec- tions (views) of this process infor- mation could be prepared as output for direct use, by automatic or semiautomatic translation. The major challenges are in defining the common denominator schema, developing translators, and ensur- ing consistency between the input representations.

Use in process Improvement A software process movement emerged in the mid-1980s when shortcomings in managing the de- velopment process were recognized as prime inhibitors of growth in software productivity and quality. Since the payback from inserting technology has been modest [39], greater leverage for improving project results appears to reside in better management of the software process. When the noise created by poorly defined or badly managed

C O M M U N I C A T I O N S OF THE ACM/September 1992/Vol.35, No.9 8 ~

processes is removed from a proj- ect, the impact of technology is more easily observed in project out- comes [16]. Software development organizations are finding that they should first focus on defining the processes used in their software business, and only then select tools and methods to support these pro- cesses. Thus, when used to inte- grate people, tasks, tools, and methods, a well-defined and docu- mented software process can pro- vide an underlying foundation for long-term productivity and quality growth [13, 16].

Effective use of defined pro- cesses requires that a process be documented, that personnel be trained in its application, that it gets performed as it is documented, and that its performance is enforced and measured. Once a process is defined in this manner, it can be deliberately and methodically im- proved.

Unfortunately, many software organizations are crisis-driven, and their processes are ad hoc and occa- sionally even chaotic [13]. In such environments, it is difficult to make lasting improvements in the soft- ware process. Humphrey devel- oped a model of how organizations can mature their software processes and steadily improve their capabil- ity for meeting schedules and bud- gets with high-quality software. This Capability Maturity Model postulates five levels of growth, each of which lays a foundation for establishing improvements at the next level.

At the initial level of the model, crisis-driven organizations are fire- fighting, and display little evidence of a defined development process that can be repeated. The primary objective in moving to Level 2, the repeatable level, is to get project management under control. This control is established through sound project planning and track- ing, management of subcontrac- tors, controlling product baselines and changes to requirements, and assuring the quality of management processes. Process modeling can be

employed in these organizations to define the processes to be per- formed in these vital areas.

Having built a sound manage- ment infrastructure that is capable of making sensible commitments for work, the focus at Level 3 shifts to defining an organization-wide software process that can be tai- lored to the conditions of each proj- ect. Process modeling techniques that were useful in defining the management processes that must be established at Level 2, are essen- tial for building the process engi- neering infrastructure at Level 3. The defined software engineering process at Level 3 becomes an orga- nizational asset that represents what the organization knows about performing its technical business [10]. This asset can be matured and refined with future experience to become a competitive advantage in knowing how to produce high- quality software in less time for less cost. In many other industries pro- cess efficiency has become a major competitive factor in the market- place.

At Level 4, the defined process is instrumented with detailed mea- sures in order to set quality targets for both the product and the pro- cess. Statistical quality control prin- ciples can be applied to different process elements by being able to ask such questions as, "What is the defect removal efficiency of each of our different kinds of reviews, walkthroughs, or testing methods?" At Level 5 the detailed measures installed at Level 4 are used to guide programs of continuous pro- cess improvement, technology in- novation, and defect prevention.

Software process modeling tech- niques are essential for supporting process improvements at levels 4 and 5. Models provide a solid framework for defining measure- ment points and metrics at level 4. Analysis of the models can identify improvement opportunities for consideration. Level 5 requires de- tailed models that can forecast the quantitative impact of potential process changes and guide selection

among alternatives. A means of recording and analyzing previous outcomes to form an experience base is another capability needed for software process modeling at level 5.

The SEI has used the Capability Maturity Model in helping several military and aerospace organiza- tions [16] improve their software process. Experience in these pro- grams indicates that extensive ef- fort is involved if an organization has few defined processes and ex- hibits large differences in the way individual projects are conducted. Implementing a successful process improvement program requires that such organizations first iden- tify the processes they want to im- prove according to their current level of maturity. They must docu- ment their current practices as a baseline on which they can build new processes and against which they can compare improvements. They must then formally define the processes they want to install. A crucial attribute of a defined pro- cess is that it be measurable. The measures taken on defined pro- cesses can be used to determine their effectiveness and to guide subsequent improvements. Build- ing new processes on top of the cur- rent process baseline, rather than installing an entirely new process, is important in order to keep the or- ganization from becoming disori- ented during the improvement program. Process modeling has been used to identify shortcomings and other improvement opportuni- ties in real world baseline processes [20, 231.

use in Software Project Management A growing body of work is focused on using process modeling to sup- port the management of software development and evolution. Sup- port for both planning and replan- ning during process performance should enable managers to plan schedules, costs, and resources while varying the resource con- straints, and accommodating deter-

8 6 September 1992/%1.35, No.9/COMMUNICATIONS OF THE ACM

a r t i c l e s

ministic or stochastic modeling. Kellner recently examined model- ing support for management plan- ning and control available in STATEMATE-based modeling, and illustrated these capabilities [21]. Among the other techniques addressing this problem, Krasner and Terrel use a project manage- ment tool with CPM; system dy- namics has been productively em- ployed to forecast project-level plans and the impact of changes [ 1, 26]; and the Articulator [28] is based on A1 scheduling techniques from production systems.

Another important element of planning involves the construction of a suitable process from a reper- toire of components. The A1 plan- ning paradigm used by GRAPPLE [12] provides an automated, goal- driven approach to this problem. Boehm and Belz have proposed a process model generator based on a decision table and various life-cycle processes [5]. Finally, work by Basili and Rombach [3], Krasner and Terrel (this issue), and at the SEI, are exploring reuse-based mecha- nisms for developing proj- ect-specific software processes.

Process-Based Software Development Environments The objectives of automated execu- tion support and automated guid- ance have received the attention of the largest number of researchers. The research community's interests in process, tools, and environments have found a unifying basis in the concept of "process-driven envi- ronments." Existing software engi- neering environments only support a fraction o f the tasks included in a sophisticated software development or maintenance process. In the ab- sence of a defined software process, it is difficult to identify:

• the complete suite of tools needed to support the entire pro- cess, * how these tools should be inte- grated to support actual work, and * how to design a software devel- opment environment that coordi-

nates the work of many software engineers.

These environments provide automated support for software work based on a process model that controls some of the functionality of the environment. This control is achieved by having the components

a usable model of the development process.

MARVEL is a multiuser, pro- cess-driven software development environment, offering rule-based process modeling and controlled automation. MARVEL was devel- oped by Kaiser and her colleagues

EARLIER STEPS J [ LATER_STEPS }

Cr ' , CODE_DEVEL" "~ CODE_N COM PILE ~J~

/ " ~ COMPILED [CLEAN] ( [REWORK_CODE] " ~

-{ DEVELOP_TESTSJ T_ EVEL

~ W O R K _ T E S T S ]

Behavioral Perspective- Statechart

I FACILffY_MGMT

Ii r--'--- " ~ 4 I COMPUTER_FILES ~ 1 I ~ l , , rj

o_.

~_E~aINEER,NG + [ SW_DEVELOPERS J QA I

HAND_CARRIED_I I L HAND CARRIED_2

I Organizational Perspective - Module Chart

I t COMPUTER_FILES t t I

CODE TEST_FiLES

[ UN~_DEV_FC~-DE~ ', I ! I

Functional Perspective - Activity Chart

DEV MODULE_TESTS descrlpUon: Task ot planning and developing

unit tests for a module. executed throughout: DEVELOPTESTS carried oul by: QA attributes: NAME: VALUE: USES FACILITY DVLPMT_SUtTE

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

HAND_CARRIED 2 contains: CODE_LISTINGS; TEST_PLANS

Interconnections Textual Information

of the environment automatically conform themselves to support the defined process. Some of the earli- est research on process-driven envi- ronments was conducted by the Arcadia consortium.

An early commercial example of a process-driven environment was ISTAR [8] which enforced a contractual model of software de- velopment where contracts for de- veloping components were let hier- archically. Software engineers re- ceived access to the tools and data associated with a contract they had accepted through a workdesk that organized their view of the devel- opment environment. ISTAR ex- perienced some difficulty with the rigidity of the contractual model as

Figure 3. Example STATEMATE model for code and test development

[17, 18] primarily at Columbia Uni- versity. The key goals o f MARVEL are to: • define processes • enact as much of the software process as possible • provide controlled automation of commercial-off-the-shelf (COTS) tools within a software develop- ment environment • support multiple users cooperat- ing on a software project

MARVEL's focus is on the objec- tive (Table 1) of automated execu- tion support. MARVEL employs a

COMMUNICATIONS OF THE ACM/September 1992/Vol.35, No.9 8 7

rule-based approach based on ideas from languages used for knowl- edge-based systems (e.g., OPS5 and Prolog). The under ly ing parad igm uses typed parameters , precondi- tions, the process elements (cur- rently restricted to simple tool invocations), and postconditions.

tam. Each process step corresponds to

a user command that is encapsu- lated with a condit ion that must be satisfied before its invocation, and an effect that asserts the state to exist at the complet ion of the pro- cess step. A process step in MAR-

Input Representations t - one or more of various modeling approaches - used for development

of process

Translation / I transformation to CDR: automated - - direct input - - translation

Common Denominator f Representation (CDR) - union of vital process

information

Translation / I transformation from CDR: automated or semi-automated

Output Representations I - intended for presentation - one or more of various

modeling approaches - may be documentation

style - use for further process engineering

INPUT REPRESENTATIONS Repr A Repr B

__' - 11 - Repr C

, \ / CDR

Schema

Instances of Processes f

Repr C"

OUTPUT REPRESENTATIONS

F igure 4. Common denominator rep- resentation concepts

Control led automation in MAR- VEL is provided th rough op- portunistic processing employing backward chaining and forward- chaining. Backward-chaining at- tempts to satisfy precondit ions when a user requests the execution of a process step. Forward-chaining is appl ied to move to the next pro- cess step when a user completes a step. MARVEL also employs an object-oriented data model, and includes an object management sys-

VEL typically invokes a tool th rough a shell script. MARVEL is an instance of a rule-based process server. Kaiser argues that such models can be evaluated by the type of assistance they support . MAR- VEL supports a pure automat ion model, since it invokes tools auto- matically, in contrast to a pure con- sistency-checking model that does not invoke tools.

MARVEL emphasizes the func- tional and behavioral perspectives of software process modeling, along with those aspects of the in- formational and organizational perspectives relat ing to automation.

The MARVEL system has evolved th rough several successive proto- types, and a recent prototype in C is available for trial use. I t has been appl ied to several small environ- ments involving C p rog ramming and document product ion, and has recently been appl ied in a commer- cial application.

A broad range of research proj- ects are cont inuing to apply process concepts to envi ronment design. These projects have in common the notion of work dis t r ibuted across workstations, pe r fo rmed on arti- facts with a def ined structure, and coordinated th rough sets of de- pendencies and constraints. The future for such environments de- pends on the extent to which more of the artifacts and resources of software deve lopment exist and are manipula ted within the virtual world of a network ra ther than in the manual world of desks and bookshelves. Thus, process-driven environments will experience a gradual evolution in use ra ther than a revolution, because they can- not be effectively used beyond the level of process definit ion an orga- nization has been able to institu- tionalize.

C o n c l u s i o n Process model ing work is young, and the span of the research agenda is still being formulated. The software phenomena best modeled using each of the repre- sentational techniques discussed in this article vary. Consequently, the structure and attr ibutes of models built with each of these techniques will differ. Since the field is young, results have been scattered in local- ized areas and few methods have been appl ied to large phenomena . A review of this l i terature in a few years may provide a much more definitive assessment of the re- search issues as the experience as the applicat ion base grows. Never- theless, work to date holds promise for benefits in management , pro- cess-driven environments , and pro- cess reengineer ing.

~ September 1992/Vo1.35, No.9/COMMUNICATIONS OF THE ACM

a r t i c l e s

Acknowledgments The authors gratefully acknowl- edge the comments of Bob Balzer, Herb Krasner, and Lee Osterweil on an earlier draft of this article, in addition to others provided by anonymous reviewers. The produc- tion of this article was supported in part by the Defense Advanced Re- search Projects Agency (DARPA)/ Software Technology for Adapt- able, Reliable Systems (STARS) program. The authors appreciate the support and encouragement of their process modeling work by John Foreman on this program. The opinions expressed in this ma- terial are those of the authors and do not necessarily reflect those of DARPA or the Software Engineer- ing Institute. []

References 1. Abdel-Hamid, T.K. and Madnick,

S.E. Software Project Dynamics: An Integrated Approach. Prentice-Hall, Englewood Cliffs, N.J., 1991.

2. Balzer, R. A 15 year perspective on automatic programming. IEEE Trans. Softw. Eng. 11, 11 (1985), 1257-1268.

3. Basili, V.R. and Rombach, H.D. Support for comprehensive reuse. Softw. Eng. J. 6, 5 (1991), 303-316.

4. Boehm, B. A spiral model of soft- ware development and enhance- ment. IEEE Comput. 21, 5 (1988), 61-72.

5. Boehm, B. and Belz, F. Experiences with the spiral model as a process model generator. In Proceedings of the Fifth International Software Process Workshop. 1EEE Computer Society, Washington, DC, 1990, pp. 43-45.

6. Curtis, B., Krasner, H. and Iscoe, N. A field study of the software design process on large systems. Commun. ACM 31, 11 (1988), 1268-1287.

7. Curtis, B., Krasner, Shen, V. and Iscoe, N. On building software pro- cess models under the lamppost. In Proceedings of the Ninth International Conference on Software Engineering. IEEE Computer Society, Washing- ton, DC, 1987, pp. 96-103.

8. Dowson, M. ISTAR--An inte- grated project support environ- ment. In Proceedings of the Second ACM Software Engineering Symposium on Practical Software Development Environments. ACM SIGPLAN Not. 22, 1 (1987), 27-34.

9. Dowson, M., Nejmeh, B. and Rid- dle, W. Concepts for process defini- tion and support. In Proceedings of. the Sixth International Software Process Workshop. IEEE Computer Society, Washington, DC, 1991, pp. 87-90.

10. Frailey, D.J. A corporate-wide soft- ware process. In Proceedings of the First International Conference on Soft- ware Process. IEEE Computer Soci- ety, Washington, DC, 1991, pp. 113-121.

11. Holt, A., Ramsey, H.R. and Grimes, J. System technology as a basis for a programming environ- ment. ITT Electr. Commun. 57, 4 (1983).

12. Huff, K.E. and Lessor, V.R. A plan- based intelligent assistant that sup- ports the software development process. In Proceedings of the Third Software Engineering Symposium on Practical Software Development Envi- ronments. Software Eng. Not. 13, 5 (1989), pp. 97-106.

13. Humphrey, W. Managing the Soft- ware Process. Addison-Wesley, Read- ing, Mass., 1989.

14. Humphrey, W.S. and Feiler, P.H. Software process development and enactment: Concepts and defini- tions. Tech. Rep. SEI-92-TR-4. Pittsburgh: Software Engineering Institute, Carnegie Mellon Univer- sity. To be published, 1992.

15. Humphrey, W.S. and Kellner, M.I. Software process modeling: Princi- ples of entity process models. In Proceedings of the Eleventh Interna- tional Conference on Software Engi- neering. IEEE Computer Society, Washington, DC, 1989, pp. 331- 342.

16. Humphrey, W.S., Snyder, T.R. and Willis, R.R. Software process im- provement at Hughes Aircraft. IEEE Softw. 8, 4 (1991), 11-23.

17. Kaiser, G.E., Barghouti, N.S. and Sokolsky, M.H. Preliminary experi- ence with process modeling in the Marvel software development envi- ronment kernel. In Proceedings of the 23d Annual Hawaii International Con- ference on System Sciences, Vol. H- - Software Track. IEEE Computer So- ciety, Washington, DC, 1990, pp. 131-140.

18. Kaiser, G.E., Feiler, P.H. and Popovich, S.S. Intelligent assistance for software development and maintenance. IEEE Softw. 5, 3 (1988), 40-49.

19. Katayama, T. and Motizuki, S. What has been learned from apply-

ing a formal process model to a real process? In Proceedings of the Seventh International Software Process Work- shop. IEEE Computer Society, Washington, DC, 1992. To be pub- lished, 1992.

20. Kellner, M.I Software process mod- eling: Value and experience. SEI Tech. Rev. Software Engineering Institute, Carnegie Mellon Univer- sity, Pittsburgh, Pa., 1989, pp. 22- 54.

21. Kellner, M.I. Software process modeling support for management planning and control. In Proceedings of the First International Conference on the Software Process. IEEE Computer Society, Washington, DC, 1991, pp. 8-28.

22. Kellner, M.I., Feiler, P.H., Finkle- stein, A., Katayama, T., Osterweil, L.J., Penedo, M.H., Rombach, H.D. ISPW-6 software process example. In Proceedings of the First Interna- tional Conference on the Software Pro- cess. IEE E Computer Society, Wash- ington, DC, 1991, pp. 176-186.

23. Kellner, M.I. and Hansen, G.A. Software process modeling: A Case study. In Proceedings of the 22d An- nual Hawaii International Conference on System Sciences, Vol. H--Software Track. IEEE Computer Society, Washington, DC, 1989, pp. 175- 188.

24. Kellner, M.I. and Rombach, H.D. Session summary: Comparisons of software process descriptions. In Proceedings of the Sixth International Software Process Workshop. IEEE Computer Society, Washington, DC, 1991, pp. 7-18.

25. Lehman, M.M. Process models, process programs, programming support. In Proceedings of the Ninth International Conference on Software Engineering. IEEE Computer Soci- ety, Washington, DC, 1987, pp. 14- 16.

26. Lin, C.Y. and Levary, R.R. Com- puter-aided software development process design. IEEE Trans. Softw. Eng. 15, 9 (1989), 1025-1037.

27. MacLean, R. Session summary: Enaction formalisms. In Proceedings of the Fourth International Software Process Workshop. IEEE Computer Society, Washington, DC, 1989, pp. 11-13.

28, Mi, P. and Scacchi, W. Modeling articulation work in software engi- neering processes. In Proceedings of the First International Conference on the Software Process. IEEE Computer

C O M M U N I C A T I O N S OF THE ACM/September 1992/Vol.35, No.9 8 9

a r t i c l e N

Society, Washington, DC, 1989, pp. 188-201.

29. Minsky, N.H. Law-governed sys- tems. Softw. Eng.J. 6, 5 (1991), 285- 302.

30. Osterweil, L. Software processes are software too. In Proceedings of the Ninth International Conference on Software Engineering. IEEE Com- puter Society, Washington, DC, 1987, pp. 2-13.

31. Ould, M.A. and Roberts, C. Model- ing iteration in the software pro- cess. In Proceedings of the Fourth In- ternational Software Process Workshop. IEEE Computer Society, Wa,;hing- ton, DC, 1987, pp. 101-104.

32. Penedo, M.H. Acquiring experi- ences with executable software pro- cess models. In Proceedings of the Fifth International Software Process Workshop. IEEE Computer Society, Washington, DC, (1990), pp. 112- 115.

33. Riddle, W.E. Session summary: Opening session. In Proceedings of the Fourth International Software Pro- cess Workshop. IEEE Computer Soci- ety, Washington, DC, (1989), pp. 5 - 10.

34. Rombach, H.D. An experiraental process modeling language: Les- sons learned from modeling a maintenance environment. In Pro- ceedings of the Conference on Software Maintenance. IEEE Computer Soci- ety, Washington, DC, 1989, pp. 95- 96.

35. Singh, B. and Rein, G.L. Role inter- action nets (RINs): A process de- scription formalism. Tech. Rep. CT-083-92. Microelectronics and Computer Technology Corp. Aus- tin, Tex., 1992.

36. Sutton, S., Heimbigner, D. and Os- terweil, L.J. Language constructs for managing change in process

You Need Tree City USA C ity trees add the

soft touch of nature to our busy lives.

Support Tree City USA where you live. For your free booklet, write: Tree City USA, The National Arbor Day Foundation, Nebraska City, NE 68410.

Day ~nmdation

(--,._

~ , 'z;

centered environments. In Proceed- ings of the Fourth SIGSOFT Sympo- sium on Software Development Envi- ronments, Software Engineering Notes 15, 6 (1990), pp. 206-217.

37. Sutton, S.M., Ziv, H., Heimbigner, D., Yessayan, H.E., Maybee, M., Osterweil, UJ. and Song, X. Pro- gramming a software-requirements specification process. In Proceedings of the First International Conference on the Software Process. IEEE Computer Society, Washington, DC, 1991, pp. 68-89.

38. Suzuki, M. and Katayama, T. Meta- operations in the process model HFSP for the dynamics and flexibil- ity of software processes. In Proceed- ings of the First International Confer- ence on the Software Process. IEEE Computer Society, Washington, DC, 1991, pp. 202-217.

39. Vosburgh, J., Curtis, B., Albert, B., Wolverton, R., Malec, H., Hoben, S. and Liu, Y. Productivity factors and programming environments. In Proceedings of the Seventh Interna- tional Conference on Software Engi- neering. IEEE Computer Society, Washington, DC, 1984.

40. Goldman, N. and Narayanaswamy, K. Software Evolution through lt- erative Prototyping. In Fourteenth International Conference on Software Engineering (May 1992), pp. 158- 172.

CR Categories and Subject Descrip- tors: D.2.1 [Software]: Software En- gineering - - requirements/specifications; D.2.10 [Software]: Software Engi- neering-design; 1.6,0 [Computing Methodologies]: Simulation and Mod- eling-general; 1.6.3 [Computing Meth- odologies]: Simulation and Modeling --applications; K.6.3 ]Computing Mi- lieux]: Management of Computing and Information Systems--software manage- ment; K.6.4 ]Computing Milieux]: Man- agement of Computing and Informa- tion Systems--system management

General Terms: Design, Methodology Additional Key Words and Phrases:

Analysis, Modeling

About the Authors: BILL CURTIS is the director of the Software Process Program in the Soft- ware Engineering Institute at Carnegie Mellon University. This program is a national focal point for improving the processes used in American industry and government for developing and maintaining software. Work in the pro-

gram has included developing and transferring into use the Capability Maturity Model for Software; process assessment, definition, and measure- ment; process modeling techniques to support process-driven environments; capability evaluation; and process im- provement programs. In addition, be maintains researeh interests in the cog- nitive and behavioral aspects of software engineering, user interface technology, coordination systems, and quality and process measurement systems.

MARC I. KELLNER conducts research and development into software process issues on the Software Process Defini- tion Project at the Software Engineering Institute (SEI). Kellner has pioneered much of the research on software pro- cess modeling conducted at the SEI, and has published several papers on soft- ware process issues. Prior to joining the SEI, Kellner was a professor at Carnegie Mellon University, where he established and directed a degree program in infor- mation systems. His research interests include software processes, software process modeling, software mainte- nance, and quality management for software.

JAMES OVER is a senior member of the technical staff, and project leader of the Software Process Definition project at the Software Engineering Institute (SEI). Before joining the SEI, Over was director of information systems for Pul- itzer Publications, Chicago, Illinois. He is the coauthor of several publications on process definition and improvement, applications of technology to document maintenance, and documentation tools in software maintenance environments. His interests include the software pro- cess, process management and improve- ment, and process modeling and defini- tion.

Authors' Present Address: Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213-3890

Permission to copy without tee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.

© ACM 0002-0782/92/0900-075 $1.50

0 September 1992/Vo1.35, No.9/COMMUNICATIONS OF THE ACM