Process Modeling by Kashif Gibbs

articles

Bill C u r t i s , M a r ( : I. K e l l n e r a n d J i m O v e r

Process

Modeling

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 information technology extend computer use beyond transaction processing into communication 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 business 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 software-related management and staff; it provides embedded support 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 distributed, 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 modeling in other areas of information science. Process modeling is distinguished from other types of modeling in computer science because many of the phenomena modeled must be enacted by a human rather than a machine. At least some modeling, 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 modeling also focuses on interacting behaviors 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 organizations, since the software engineering community is already accustomed to formal modeling. Software process modeling, in particular, explicitly focuses on phenomena that occur during software creation and evolution, a domain different from that usually modeled in human-machine integration or information systems design. Software development is a challenging focus for process modeling because of the creative problemsolving involved in requirements analysis and design, and the coordination of team interactions during the development of a complex intellectual artifact. In this article, software process modeling will be used as an example application for describing the current status of process modeling, issues for practical use, and the research questions that remain ahead. Uses for Process Models

Most software organizations possess several yards of software life cycle

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

description, enough to wrap endlessly around the walls of project rooms. Often these descriptions do not correspond to the processes actually 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 implementation handbook. This lack of fidelity between actual behavior and the organization's stated process is caused by such factors as: • high-level prescriptive processes that are unrelated to actual project activities, • imprecise, ambiguous, incomprehensible, or unusable descriptions of processes to be performed on the project, and • failure to update the documentation as processes change. These large-grained life-cycle descriptions depict different phases abstractly and some may describe the point at which different functional groups will become involved in the project. Traditionally, these representations have been considered process models. However, the software process modeling community has not been satisfied with using existing life-cycle descriptions as process models, because the granularity of the process steps included 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-

U~tiCZ~t]

aging and coordinating the project. For instance, traditional life-cycle descriptions might show phasee n d i n g reviews, but not the myriad within-phase reviews that are necessary for developing a quality product. Further, life-cycle descriptions are most often treated as linear sequences, where crucial attributes o f the process such as feedback loops and iteration are not r e p r e s e n t e d [4, 7]. Research on software process modeling supports a wide range o f objectives [20, 33]. Five basic uses for process models, ranging from u n d e r s t a n d i n g aids to a u t o m a t e d execution support, are presented in Table 1. These categories are:

a u t o m a t e d tools for manipulating process descriptions

u n d e r s t a n d i n g or predicting the p h e n o m e n a modeled. Selecting bounds for the p h e n o m e n a to be m o d e l e d d e p e n d s on the uses to which the model will be put. H u m p h r e y and Feiler [14] have presented a foundational lexicon on which to build a conceptual framework for software process modeling and definition. T h e y define a process as "a set o f partially o r d e r e d steps i n t e n d e d to reach a goal." Any c o m p o n e n t o f a process is a process element. A process step is "an atomic action o f a process that has no externally visible substructure." Determining that a process element is a process step d e p e n d s in part on whether any further decomposition o f the element's structure is n e e d e d to s u p p o r t the objectives of the process model. In o r d i n a r y usage a task is often synonymous with a process a n d an activity is synonymous with a process element or step. We will, however, avoid these terms for the sake o f clarity. Although there is not widespread consensus on the constructs that collectively form the essential basis o f a process model, the following list includes many o f those most frequently mentioned (abstracted from [9, 14, 27, 35]).

Automate execution support requires a

Agent--an actor (human or ma-

computational basis for controlling behavior within an automated environment.

chine) who p e r f o r m s a process element.

Facilitate human understanding and communication requires that a g r o u p be able to share a c o m m o n representational format

Support process improvement requires a basis for defining and analyzing processes

Support process management requires a defined process against which actual project behaviors can be compared

Automate process guidance requires

T h e issues raised by these objectives range from comprehensibility to enactability. Before discussing these issues we need to establish a conceptual f r a m e w o r k for process modeling.

Conceptual FrameworR A model is an abstract representation of reality that excludes much o f the world's infinite detail. T h e p u r p o s e of a model is to reduce the complexity o f u n d e r s t a n d i n g o r interacting with a p h e n o m e n o n by eliminating the detail that does not influence its relevant behavior. T h e r e f o r e , a model reveals what its creator believes is i m p o r t a n t in

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

Artifact--a p r o d u c t created or modified by the enactment o f a process element. A single agent can p e r f o r m multiple roles (e.g., designer, reviewer, coder), and a single role (coder) may be p e r f o r m e d by multiple agents. A process can now be further elaborated as one or m o r e agents acting in defined roles to enact the process steps that collectively accomplish the goals for which the process was designed. Typically, process steps either manipulate an artifact or coordinate

dependencies with other agents involved in the same or a related process. Consequently, process steps should be p l a n n e d as part of a defined process, assigned to a role, allocated resources, and monitored. A process model is an abstract description of an actual or proposed process that represents selected process elements that are considered i m p o r t a n t to the purpose o f the model and can be enacted by a h u m a n or machine. T h e levels of abstraction within the d o m a i n o f software d e v e l o p m e n t range from the detailed process steps executed entirely on a machine, to the l a r g e r - g r a i n e d h u m a n processes involved in executing a life-cycle phase, to the abstract stages o f the life-cycle chosen for the product. Defined or not, the collection o f all the process steps executed to develop a software system constitutes a software developm e n t process. T h e s e processes, however, do not constitute a software process model until they are r e p r e s e n t e d in some medium. A process model to be p e r f o r m e d by a h u m a n will be called a process script, while one to be enacted by a machine will be called a process program [14, 30]. Most life-cycle descriptions represent an extremely abstract model o f software d e v e l o p m e n t and do not provide clear guidance on how to integrate the many process steps that project staff p e r f o r m . O n e o f the objectives o f software process modeling is to d e c o m p o s e these descriptions into sufficient detail so that they can provide m o r e explicit guidance for executing a software d e v e l o p m e n t project. Since many projects are m a n a g e d as loose collections o f process elements that constitute different tasks (an unintegrated set o f process fragments), projects might be m a d e m o r e efficient if the process elements and steps u n d e r l y i n g different processes could be integrated into an efficient structure for executing the desired software d e v e l o p m e n t process.

September 1992/Vol.35,No.9/COMMUNICATIONSOF THE Ai~M

articles

P e r s p e c t i v e s in Process Representation

Many forms of information must be integrated to adequately describe software processes. A m o n g 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 dependent on its being done. Processmodeling languages differ in the extent to which their constructs highlight the information that answers these different questions. Process-modeling languages and representations usually present one or more different perspectives related to these questions. Four of the most commonly represented perspectives 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., sequencing), as well as aspects of how they are performed through feedback loops, iteration, complex decision-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 communication mechanisms used for transfer of entities, and the physical media and locations used for storing entities.

Informational represents the informational entities produced or manipulated by a process; these entities include data, artifacts, products (intermediate and end), and objects; this perspective includes both the structure of informational entities and the relationships among them. These perspectives underlie separate yet interrelated representations for analyzing and presenting process information (Figure I).

Software

• • • • •

T a b l e 1. P r o c e s s 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 complete model of the process analyzed. This hypothesis, however, needs verification through experimental process modeling. Integration and consistency may be easier to demonstrate, since completeness is relative to the application. Completeness depends on whether all important components of information 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 perspectives offered. In practice, most process de-

COMMUNICATIONSOFTHEACM/September 1992/Vol,35, No.9

scriptions have employed narrative text and simple diagrams to express process, with the text often structured in a uniform way (e.g., inputs, outputs, activity description). Many conventional uses of process models have posed few requirements on the formal properties of the representation, since their use was more for communication than for analysis. T h e 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, however, it is easier for modelers to interleave many perspectives in a process description. Unfortunately, it is difficult to analyze the properties of these perspectives when the

representation has not been formally constrained. Process Modeling 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 representing, reasoning about, and enacting a computational process, Figure 1. Concept of process perspectives

most researchers have started from this language base in modeling software processes. They often begin by proposing language structures and formalisms for modeling. Osterweil [30] has pointed out a chicken-and-egg problem in exploring 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 modeling languages derived from them have been proposed in the past several years. Table 2 identifies the language types and constructs supported by several of the processmodeling 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 language types and constructs support the four perspectives discussed in the preceding section. Comparing the profiles between these two tables provides a summary analysis of

top perspective (e.g., functional)

right perspective (e.g., organizational)

Actual Pro(

/ left perspective (e.g., behavioral)

back perspective (e.g., informational)

September 1992/Vol.35,No.9/COMMUNICATIONSOFTHE ACM

Ir~lcles

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 software processes [17, 19, 20, 23, 32, 34]. Feedback between language development and application experience 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 research, five approaches to representing 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 approaches. These five approaches to modeling, each described through an example technique, are:

Functional models--HFSP Plan-based models--GRAPPLE Petri-net models--role interaction nets

Quantitative models--system dynamics. P r o g r a m m i n g Models

Programming models--process pro-

In stating the case for process programming, Osterweil [30] argues that "software processes are software, too." That is, since specifying a process is a form of programming, processes can be modeled with all the tools and techniques of the programmer's trade. T h e resulting programs are bound to humans as well as machines. Osterweil maintains that people develop process descriptions to solve problems. These descriptions can be modeled as algorithms and can be analyzed accordingly. Osterweil and his colleagues developed APPL/A [36] for constructing process programs that can he enacted by a machine: APPL/A [36] and p4

gramming

[10].

The Ada Process Programruing Language based on Aspen (APPL/A) allows processes to be modeled in an extension of Ada that enables explicit representation of programmable, persistent relations. Aspen is a data model for software engineering that incorporates 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 represent constraints. Process programming has often been unfairly characterized as a purely procedural approach. Since it provides both procedural and declarative capabilities, APPL/A supports multiple representational paradigms, an approach to process modeling that will be discussed in a later section. Sutton et al. [37] have used APPL/A to implement a t o o l - R E B U S - - t h a t supports the process

11:ble 2. L a n g u a g e Types a n d C o n s t r u c t s 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 and Constructs

Sample SOftware PrOCeSS Modeling Approaches

Procedural programming languages

APPL/A [361

Systems analysis and design 1

STATEMATE [20]

AI languages and approaches 2

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

Events and triggers

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

State transition and petri-nets

Role Interaction Nets [35], STATEMATE [20]

Control flow

MVP [34]

Functional languages

HFSP [38]

Formal languages

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 2--including 3--including 4--including 5--including

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

COMMUNICATIONS OF THE

ACM/September 1992/Vol.35, No.9

Ilrticles

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 interaction in the shared requirements workspace that otherwise burdened the analysts with unnecessary process steps. T h e formality enforced in REBUS emanated from the formal structure of the requirements document, rather than from the structure of the process. Thus, while individual methods for performing activities and tasks were not controlled, the emerging structure of the artifact and the group interaction process for producing it were controlled. Although smallgrained concurrency control was provided, a need surfaced for a larger-grained version that was not supported in APPL/A. T h e modeling 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 capabilities that will be crucial in scaling up automated process models to support process-based environments. F u n c t i o n a l Models

T h e Hierarchical and Functional Software Process (HFSP) description and enaction language was developed at the Tokyo Institute of Technology by Katayama and his colleagues [38]. T h e key goals of HFSP are t o : • aid process understanding • support hierarchical process decomposition • 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 diagrammatically. In HFSP, a process is represented as a collection of process

T a b l e 3. Perspectives f o r Process I n f o r m a t i o n and Applicable Language Bases Perspectives

Procedural Programming

languages

u 1-

m e-

Systems analysis and design

/,4

Allanguages

and approaches

--=

Events and triggers state transition and petri-nets Control flow Functional languages Formal languages Data modeling Object modeling Precedence networks Notes: le.g, product structure charts 2specifically role-interaction nets

~,2

;,,,2

~' /J'

elements with input and output attributes. Specifically, a process is defined as a set of mathematical functions depicting relationships among inputs (such as specifications) and outputs (such as source codes). Furthermore, each of these functions is hierarchically decomposable into process subelements, where the input and output attributes 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 external tool invocation or manual operations. 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 information such as sequencing, iteration, and synchronization. In addition, metaoperators have been added to permit inclusion of dynamic control of behavior, such as creating, destroying, suspending, or resuming process elements, and communicating a m o n g them. Finally, a process enaction mechanism would be responsible for activity-scheduling (based on such items as resource constraints, activity execution management, tool invocation, object base access, and user interaction). HFSP is primarily oriented toward 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 permanently 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.

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

arelÂ˘les

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 interacting agents, rather than requiring that all components of a decomposed artifact be available before enabling performance of the next process element. Finally, they observed a requirement for a metalevel process to control (manage) the execution of other processes. Katayama and Motizuki concluded that in trying to model actual processes, they might discover new processing concepts for computer science. Plan-Based Models

H u f f and Lesser argue that modeling process execution in the real world is difficult because of all the contingencies that must be considered [12]. This contingency management poses particular problems for procedural languages because the rationale underlying the design of the process has been removed from the procedural representation. The rationale is, therefore, unavailable for reasoning about enaction choices based on existing conditions within the current state of a process's execution. They propose 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 operators 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. H u f f and Lesser created a constraint-based language called GRAPPLE that models software development as a set of goals, subgoals, preconditions, constraints, and effects. GRAPPLE constructs process models from two fundamental 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 effective 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. H u f f and Lesser provide a high-level example for representing 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 currentrelease(C) ADD currentrelease (system) ADD customerrelease (system) ADD prior-release (system,C) In this example, the computational agent will seek to satisfy the goal of making 'system' the current release when a set of preconditions have been satisfied without violating the stated constraints. In contrast to procedural approaches GRAPPLE produces process plans dynamically by comparing conditions in the current state of the environment with the preconditions of the operators available for acting on it. Plan execution can be simulated to reason about the viability of selecting a particular path for the plan. The status o f satisfying different goals in the goal hierarchy is tracked as a means of guiding operator selection. Experiences with GRAPPLE revealed 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 dependencies. These descriptive attributes o f

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

the artifact provided a rich source of constraints for guiding the selection of operators. H u f f and Lesser also identified a need to integrate multiple sources of knowledge representation and an analysis capability for deriving the properties of processes. Petri-Net Models One view of a project that is orthogonal to the perspective portrayed by most programming languagebased models is provided by its structure of roles and their interaction. 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 project using a Petri-net-based representation and language. The technique employed at MCC was derived from a Petri-net-based language called RADDLE developed by Ira Forman for use in modeling high-level designs for a distributed system. Extensive modifications, however, had to be made to the formalism to provide the flexibility needed for the system to be used in aiding human coordination. For instance, the tight concurrency control enforced in computing systems often must be relaxed (but in systematic ways) when humans are the agents of execution. Extensive modeling of industrial software processes resulted in additions to the model for scalability. The Petri-net-based role interaction model has now been used in a commercial product. Role interaction nets are designed to aid the representation and execution o f structured tasks. Structured tasks are those that can be planned from known dependencies. One possible process for conducting a technical review is modeled in role interaction nets in Figure 2 (the figure has been simplified to remove the representation of iteration). Role interaction

el F C; :: ,~ : :Z ,,'Z S;

nets are strong in representing roles, dependencies, and process elements. Its representation of artifacts, however, is weak. When a process has been represented in role interaction nets, a new notion of teams emerges, built on dependencies among roles, rather than on reporting relationships. Where interactions among roles are frequent, a clustering of roles forms a de facto team. A process 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 individuals. Having instantiated a project plan, role interaction nets can be used as a method of coordinating the routing of artifacts among interacting roles and as a method of tracking progress by the completion of interactions among :roles. That is, this formalism can be used as an underpinning for coordinating 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 techniques that involves quantitative representation is system dynamics, which applies feedback and control system techniques to social and industrial phenomena. Models built using system dynamics techniques attempt to define a set of quantitative relationships a m o n g variables of interest that simulate the observed 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 chronically 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 because 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. T h e simulated behavior presents one possible model of the 90%-complete syndrome 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 n u m b e r of modules that have successfully passed the integration test phase, or the n u m b e r of problem reports closed. Thus, the perceived work accomplished was modeled as: PWA = [VF * (% resources consumed)] + [(1 - VF) * (actual % work finished)] where, PWA = perceived 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 reproduce through modeling techniques that do not provide dynamic feedback loops. T h e value of these models is very much tied to the closeness with which their constructs and parameters represent actual states observed on real projects.

Issues in Process Modeling Formality A primary issue in the research agenda involves the level of mathematical formality needed in process-modeling languages. Scaling on this dimension represents a language's level of formal precision in representing the process. A formally precise language is enactable on a machine. T h e level of formality required may depend on the purpose served by the process model and the agent responsible for enacting the specified processes. 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 describing process programming [30]. However, Lehman [25] and Curtis et al. [7] maintain that computer programming is too deterministic a paradigm for processes to be enacted by humans. This problem has motivated the distinction between process programs and process scripts. They argue that while computers have precise execution semantics, humans do not. Osterweil indicates that many software development processes are only partially automated, involving interaction between h u m a n and computer agents. Although some languages (e.g., systems analysis and design languages) have been used to depict both automated and manual processes, many extensions of existing programming languages have only been applied to those process components being automated. Flexibility in representing manual tasks performed by humans is a fundamental requirement for developing process scripts [10]. Humans exhibit far more variability than computers in executing a defined 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

September 1992/Vol.35, No.9/COMMUNICATIONS

OF T H E ACM

articles

precision in parsing process instructions. Experience shows that even those using formal specification languages often have run their specifications back t h r o u g h a translator to p r o d u c e a natural language version that was m o r e understandable [2]. Unfortunately, interest in facilitating h u m a n u n d e r s t a n d i n g and communication has received less attention from the research community than has machine enaction. Process models and definitions cannot be used if they cannot be understood. T h e large n u m b e r o f potential process model users, such as software process engineers, project managers, software engineers, system engineers, software executives, and customer m a n a g e m e n t makes it difficult to establish a universally u n d e r s t o o d representation format. Due to their individual information needs and expertise, these groups place widely diverging d e m a n d s on a modeling approach. Visual representations, abstraction, and multiple perspectives offer promising techniques for coping with these challenges. Even so, Curtis, Krasner, and Iscoe found that a homogeneous g r o u p could spend six months developing a c o m m o n und e r s t a n d i n g o f the semantics of a representation format [6]. A process-modeling language should permit evaluation o f the adequacy o f a p r o p o s e d process. T h e model should be analyzable for such properties as syntactic correctness, consistency, completeness, correctness, risks, and o p p o r t u n i ties for improvement, a m o n g others. Most formalisms and tools typically p r o v i d e the first few types o f analysis, since they e m e r g e from the formal properties o f the representation. However, a representation's formal properties can support more advanced analyses such as reachability o f various process states, detection of deadlocks, and race conditions in the process, detection of behavioral ambiguities [20, 23]. These analyses are provided 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 b o u n d e d by the model [23]. However, if no anomalies are found, an i m p o r t a n t degree o f assurance has been provided that the process being modeled is internally sound.

executing agent already possesses o f the contents and sequencing o f process steps, the larger the grain o f the process step that can be used in a process model. T h a t is, with greater process knowledge, largergrained modeling units can be used to invoke sequences of process steps when the model is enacted by an agent. In many domains, descriptions

Review

Leader

Member

Team

Designer

Team

Announcereviewteam

E"~d /

schedule PI. . . . iewtime-~"~

~./stribute designd. . . . .

Project Manager Update status-"~( ~ Approvereview team membersh~~

document-~I____J Sendreviewcommants~ (~Collectreviews I I Schedulereviewmeeting Receive

i __

Updatestatus~'~

~rJsem,.es,g.

I Recordminutes -'~ BIBBBI Attend and question ~ I J I \-DJstrlbutemInutes (~ ~evlew minutes ~ Review minutes ~ and actionItems

Note problems--~[~

Submit completed

,, ,.~nitrmactionitem completion

T h e external validity o f a process model must be d e t e r m i n e d by the value of its use and the degree o f fidelity it offers in depicting relevant p h e n o m e n a in the real world. Granularity and Precision

T h e granularity issue involves the size o f the process elements represented in the model. T h e pressure for greater granularity is driven by the need to ensure processprecision-the degree to which a defined process specifies all the process steps n e e d e d to p r o d u c e accurate results [14]. T h e granularity o f a process step n e e d e d to ensure process precision will d e p e n d on the purpose o f the model and attributes o f the agent that must execute the process. T h e m o r e extensive the und e r s t a n d i n g or representation the

COMMUNICATIONSOFTHEACM/September 1992/Vo1.35, No.9

Updatestatus'~~ ]

F i g u r e 2. Role interaction net for review team

for process scripts are presented to humans at too high a level o f abstraction (large-grained) and they do not provide sufficient detail for guiding actual execution. Consequently, h u m a n agents are expected to have sufficient knowledge to translate these imprecise scripts into actions by filling in detailed process steps that are a p p r o p r i a t e to c u r r e n t conditions. I f the h u m a n agent already knows many relevant potential scripts, a large-grained process model may be desirable in o r d e r to allow the agent to tailor the final detailed process script enacted. This flexibility may be especially desirable when there are complicated decision rules for selecting

and integrating the processes to be performed. If h u m a n agents do not possess sufficient process knowledge, it may be desirable to model finer-grained process steps with approaches that represent ahernative 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. Programming-language-based approaches to modeling have largely been used to represent smallgrained models that supported specific forms of process enactment on a machine, Techniques derived from design languages, especially those with strong visual representations, are often used for largergrained process models. Not surprisingly, this observation coincides with the level of abstraction normally associated with the use of these languages in software engineering. Ultimately, process models must support multiple levels of abstraction 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 modeling implies the process should be performed a particular way. Much of the process-modeling research presupposes the existence of a prescriptive process in a process modeler's mind, that is then translated into a modeling formalism. Prescriptive 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 h u m a n or machine capabilities, process fitness is low.

The prescriptive approach to process modeling can be at odds with the concept of process improvement based on continuous evolution when the prescribed process is difficult to perform (i.e., when process fitness is low [14]). T h e evolutionary approach begins with an understanding of the current process used in an organization. Descriptive modeling attempts to determine the actual processes currently 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. Managed improvement is also based on measurements of actual performance that are related to the processes actually performed (a descriptive 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 representations, and on analyzing descriptive models for those points at which process changes can be most successfully inserted in an evolutionary way. A third perspective is offered by proscriptive models, which delineate behavior that is not allowed. Lawgoverned modeling takes this approach [29], and is used for exercising control over the allowable steps that can be taken in a process. For instance, constraint-based modeling techniques such as embodied in AP5, GRAPPLE [12], and MARVEL [18] allow the modeler to indicate constraints that cannot be violated by the execution of a process. A proscriptive model might indicate that a modified module cannot resume its former status in the configuration management system until it has been regression-tested. Proscriptive modeling will most often be used as an adjunct to prescriptive or descriptive modeling. Future Directions: Field Growth In order to accelerate the growth of

process modeling, seven International 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 proceedings of this workshop (published by IEEE Computer Society Press, Washington, DC) presents the best annual review of progress in the process-modeling field. T h e field is growing, and in 1991 the First International Conference on the Software 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 processes and on process-driven environments. An important step in understanding and comparing the various approaches to software process modeling has been undertaken in conjunction with the Sixth and Seventh International Software Process Workshops (ISPW). A working group has developed a benchmark software process modeling example problem [22]. T h e original ISPW-6 Software Process Example was carefully designed to incorporate examples of 18 important process aspects and issues focusing on representation issues [24]. Additional extensions were developed for the Example in conjunction with ISPW-7, highlighting teamwork issues, and process change '. At least 24 different modeling approaches have been applied to this c o m m o n process example. As a result, the Example has provided an important b~isis for understanding, comparing, and assessing various modeling approaches. In addition, it has successfully comm u n i c a t e d - w i t h concrete exampies--the diversity of process aspects encountered in real-world software processes. As a result, several 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.

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

arl:lclas

enhanced their approaches in response to working through the Example. Multi-Paradigm Representations

The suitability of a modeling approach will depend on the goals and objectives for the resulting model [24]. A given language construct or type will be better suited to achieving some modeling objectives than others. The goals and objectives outlined in Table 1 present diverse requirements for a modeling technique that no current software process modeling approach fully satisfies. The diversity in audiences, in information content, and in the different descriptive capabilities needed for human vs. machine enaction of processes all impose broad, and sometimes conflicting, requirements on a modeling approach. An approach that integrates multiple representational paradigms is currently considered necessary for effective software process modeling. However, the application of multi-paradigm representations raises additional challenges regarding translation, communication, coordination, and interaction among model components. 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 approach is focused on supporting three of the objectives outlined in Table 1: facilitate human understanding and communication, support process improvement, and support process management. STATEMATE-based modeling provides a software design and analysis paradigm, formal visual languages, multiple integrated perspectives, and powerful automated analyses and simulations.

C O M M U N I C A T I O N S OF THE

Of the four perspectives described earlier, the STATEMATEbased approach was specifically developed to support the functional, behavioral, and organizational perspectives; it can also provide support for the informational perspective [15]. This approach supports multiple language paradigms as suggested in Table 2, including: â&#x20AC;˘ state transitions with events and triggers (used for the behavioral perspective), â&#x20AC;˘ systems analysis and design diagrams: enhanced data flow diagrams (used for the functional perspective), and modified structure charts (used for the organizational perspective) â&#x20AC;˘ data-modeling (used with the functional perspective and additional 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 modeling has been gained at the SEI in recent years, and includes major efforts at modeling large-scale software processes. The STATEMATE modeling approach has been applied to model the processes in actual use for supporting the operational software for the F-14A [20], and F-16A/B aircraft. These two models depict the full software support process from receipt of a software trouble report, change request, or enhancement request, through to release of the corresponding software change to the field. Other applications modeled processes presented in narrative prescriptions in a military handbook (MIL-HDBK-347). In these efforts, the work has progressed beyond simply representing the process, and has included manual and automated analyses of the process, followed by recommendations for process improvements based on those analyses. The application of appropriate existing technology has allowed the SEI team to focus their

ACM/September 1992/Vol.35,No.9

efforts on developing the approach and the actual models, rather than on building tools. Although a small number of language paradigms can be integrated within a single modeling approach, even more diversity may be required to meet the wide-ranging objectives of modeling. A potential strategy for coping with this challenge is illustrated in Figure 4. This technique is based on the loose integration (incorporation) of various modeling paradigms, allowing users to capitalize on their best aspects. The central research hypothesis is that a "common denominator schema" can be defined and evolved that will contain the union of all vital process information handled 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 suitable for direct user manipulation. However, automatic translators could extract the subset of information represented by a given modeling approach, and store it in an object-base (database) defined by the common denominator schema. Similarly, various additional projections (views) of this process information 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 ensuring consistency between the input representations. Use in process Improvement

A software process movement emerged in the mid-1980s when shortcomings in managing the development 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

processes is removed from a project, the impact of technology is more easily observed in project outcomes [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 processes. Thus, when used to integrate people, tasks, tools, and methods, a well-defined and documented software process can provide an underlying foundation for long-term productivity and quality growth [13, 16]. Effective use of defined processes 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 improved. Unfortunately, many software organizations are crisis-driven, and their processes are ad hoc and occasionally even chaotic [13]. In such environments, it is difficult to make lasting improvements in the software process. H u m p h r e y developed a model of how organizations can mature their software processes and steadily improve their capability for meeting schedules and budgets 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 firefighting, 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 tracking, management of subcontractors, 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 performed in these vital areas. Having built a sound management 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 tailored to the conditions of each project. Process modeling techniques that were useful in defining the management processes that must be established at Level 2, are essential for building the process engineering infrastructure at Level 3. T h e defined software engineering process at Level 3 becomes an organizational 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 highquality software in less time for less cost. In many other industries process efficiency has become a major competitive factor in the marketplace. At Level 4, the defined process is instrumented with detailed measures in order to set quality targets for both the product and the process. Statistical quality control principles 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 process improvement, technology innovation, and defect prevention. Software process modeling techniques are essential for supporting process improvements at levels 4 and 5. Models provide a solid framework for defining measurement points and metrics at level 4. Analysis of the models can identify improvement opportunities for consideration. Level 5 requires detailed 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. T h e SEI has used the Capability Maturity Model in helping several military and aerospace organizations [16] improve their software process. Experience in these programs indicates that extensive effort is involved if an organization has few defined processes and exhibits large differences in the way individual projects are conducted. Implementing a successful process improvement program requires that such organizations first identify the processes they want to improve according to their current level of maturity. T h e y must document 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 process is that it be measurable. T h e measures taken on defined processes can be used to determine their effectiveness and to guide subsequent improvements. Building new processes on top of the current process baseline, rather than installing an entirely new process, is important in order to keep the organization from becoming disoriented during the improvement program. Process modeling has been used to identify shortcomings and other improvement opportunities in real world baseline processes [20, 231. use in Software Project

Management A growing body of work is focused on using process modeling to support the management of software development and evolution. Support for both planning and replanning during process performance should enable managers to plan schedules, costs, and resources while varying the resource constraints, and accommodating deter-

September 1992/%1.35, No.9/COMMUNICATIONSOF THE ACM

articles

ministic or stochastic modeling. Kellner recently examined modeling support for management planning and control available in STATEMATE-based modeling, and illustrated these capabilities [21]. A m o n g the other techniques addressing this problem, Krasner and Terrel use a project management tool with CPM; system dynamics has been productively employed 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 repertoire of components. T h e A1 planning paradigm used by GRAPPLE [12] provides an automated, goaldriven 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 mechanisms for developing project-specific software processes.

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

EARLIER STEPS J

[ LATER_STEPS }

-{ DEVELOP_TESTSJ

COMMUNICATIONS OF THE

COMPUTER_FILES t I TEST_FiLES

T_ EVEL

[I UN~_DEV_FC~-DE~ ',

~WORK_TESTS]

Behavioral Perspective- Statechart

DEV MODULE_TESTS

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

descrlpUon: Task ot planningand developing unit tests for a module. executed throughout: DEVELOPTESTS o_.

QA L HANDCARRIED_2

Organizational Perspective

- Module Chart

of the environment automatically conform themselves to support the defined process. Some o f the earliest research on process-driven environments 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 development where contracts for developing components were let hierarchically. Software engineers received access to the tools and data associated with a contract they had accepted through a workdesk that organized their view of the development environment. ISTAR experienced some difficulty with the rigidity of the contractual model as

ACM/September1992/Vol.35,No.9

carried oul by: attributes:

~_E~aINEER,NG + [ SW_DEVELOPERSJ

Functional Perspective - Activity Chart

FACILffY_MGMT

Process-Based Software Development Environments

• the complete suite of tools needed to support the entire process, * how these tools should be integrated to support actual work, and * how to design a software development environment that coordi-

It t CODE

Cr ' , CODE_DEVEL" "~ CODE_N COMPILE~J~ / " ~ COMPILED[CLEAN] ( [REWORK_CODE] " ~

HAND_CARRIED_II

The objectives of automated execution support and automated guidance 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 environments." Existing software engineering environments only support a fraction o f the tasks included in a sophisticated software development or maintenance process. In the absence of a defined software process, it is difficult to identify:

a usable model of the development process. MARVEL is a multiuser, process-driven software development environment, offering rule-based process modeling and controlled automation. MARVEL was developed by Kaiser and her colleagues

NAME: USES FACILITY

VALUE: DVLPMT_SUtTE

............................. HAND_CARRIED 2 CODE_LISTINGS; TEST_PLANS

contains:

Interconnections Textual Information

F i g u r e 3. Example STATEMATEmodel for code and test development

[17, 18] primarily at Columbia University. T h e 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 development environment • support multiple users cooperating on a software project MARVEL's focus is on the objective (Table 1) of automated execution support. MARVEL employs a

rule-based a p p r o a c h based on ideas from languages used for knowledge-based systems (e.g., OPS5 and Prolog). T h e underlying p a r a d i g m uses typed parameters, preconditions, the process elements (currently restricted to simple tool invocations), and postconditions.

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

modeling

Translation transformation to CDR: automated direct input - - translation

Repr

Each process step corresponds to a user c o m m a n d that is encapsulated with a condition that must be satisfied before its invocation, and an effect that asserts the state to exist at the completion of the process step. A process step in MAR-

INPUTREPRESENTATIONS ReprB ReprC

- 11

__' I

tam.

CDR

Schema Common Denominator f Representation (CDR) - information union of vital process Translation / transformati on

Instances of

Processes

from CDR: automated or semi-automated

Output Representations - intended for presentation more of various modeling approaches - may be documentation style - use for further process

- oneor

engineering

Repr

C" Conclusion

OUTPUTREPRESENTATIONS

F i g u r e 4. Common denominator representation concepts

Controlled automation in MARVEL is p r o v i d e d t h r o u g h opportunistic processing employing backward chaining and forwardchaining. Backward-chaining attempts to satisfy preconditions when a user requests the execution o f a process step. Forward-chaining is applied to move to the next process step when a user completes a step. MARVEL also employs an object-oriented data model, and includes an object m a n a g e m e n t sys-

T h e MARVEL system has evolved t h r o u g h several successive prototypes, and a recent prototype in C is available for trial use. It has been applied to several small environments involving C p r o g r a m m i n g and d o c u m e n t production, and has recently been applied in a c o m m e r cial application. A b r o a d range o f research projects are continuing to apply process concepts to e n v i r o n m e n t design. These projects have in c o m m o n the notion o f work distributed across workstations, p e r f o r m e d on artifacts with a defined structure, and coordinated t h r o u g h sets o f dependencies and constraints. T h e future for such environments depends on the extent to which m o r e o f the artifacts and resources o f software d e v e l o p m e n t exist and are m a n i p u l a t e d within the virtual world o f a network r a t h e r than in the manual world o f desks and bookshelves. Thus, process-driven environments will experience a gradual evolution in use rather than a revolution, because they cannot be effectively used beyond the level o f process definition an organization has been able to institutionalize.

VEL typically invokes a tool t h r o u g h a shell script. MARVEL is an instance o f a rule-based process server. Kaiser argues that such models can be evaluated by the type o f assistance they support. MARVEL supports a p u r e automation model, since it invokes tools automatically, in contrast to a p u r e consistency-checking model that does not invoke tools. MARVEL emphasizes the functional and behavioral perspectives of software process modeling, along with those aspects o f the informational and organizational perspectives relating to automation.

Process modeling work is young, and the span of the research a g e n d a is still being formulated. T h e software p h e n o m e n a best m o d e l e d using each o f the representational techniques discussed in this article vary. Consequently, the structure a n d attributes o f models built with each of these techniques will differ. Since the field is young, results have been scattered in localized areas and few methods have been applied to large p h e n o m e n a . A review of this literature in a few years may provide a much m o r e definitive assessment o f the research issues as the experience as the application base grows. Nevertheless, work to date holds promise for benefits in management, process-driven environments, and process reengineering.

September 1992/Vo1.35, No.9/COMMUNICATIONSOF T H E

ACM

articles

Acknowledgments T h e authors gratefully acknowledge 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. T h e production of this article was supported in part by the Defense Advanced Research Projects Agency (DARPA)/ Software Technology for Adaptable, Reliable Systems (STARS) program. T h e authors appreciate the support and encouragement of their process modeling work by J o h n Foreman on this program. T h e opinions expressed in this material are those of the authors and do not necessarily reflect those of DARPA or the Software Engineering 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 software development and enhancement. 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 process models under the lamppost. In Proceedings of the Ninth International Conference on Software Engineering. IEEE Computer Society, Washington, DC, 1987, pp. 96-103. 8. Dowson, M. ISTAR--An integrated project support environment. In Proceedings of the Second ACM Software Engineering Symposium on Practical Software Development Environments. ACM SIGPLAN Not. 22, 1 (1987), 27-34.

C O M M U N I C A T I O N S OF T H E

9. Dowson, M., Nejmeh, B. and Riddle, W. Concepts for process definition 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 software process. In Proceedings of the First International Conference on Software Process. IEEE Computer Society, Washington, DC, 1991, pp. 113-121. 11. Holt, A., Ramsey, H.R. and Grimes, J. System technology as a basis for a programming environment. ITT Electr. Commun. 57, 4 (1983). 12. Huff, K.E. and Lessor, V.R. A planbased intelligent assistant that supports the software development process. In Proceedings of the Third Software Engineering Symposium on Practical Software Development Environments. Software Eng. Not. 13, 5 (1989), pp. 97-106. 13. Humphrey, W. Managing the Software Process. Addison-Wesley, Reading, Mass., 1989. 14. Humphrey, W.S. and Feiler, P.H. Software process development and enactment: Concepts and definitions. Tech. Rep. SEI-92-TR-4. Pittsburgh: Software Engineering Institute, Carnegie Mellon University. To be published, 1992. 15. Humphrey, W.S. and Kellner, M.I. Software process modeling: Principles of entity process models. In Proceedings of the Eleventh International Conference on Software Engineering. IEEE Computer Society, Washington, DC, 1989, pp. 331342. 16. Humphrey, W.S., Snyder, T.R. and Willis, R.R. Software process improvement at Hughes Aircraft. IEEE Softw. 8, 4 (1991), 11-23. 17. Kaiser, G.E., Barghouti, N.S. and Sokolsky, M.H. Preliminary experience with process modeling in the Marvel software development environment kernel. In Proceedings of the 23d Annual Hawaii International Conference on System Sciences, Vol. H - Software Track. IEEE Computer Society, 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-

ACM/September1992/Vol.35,No.9

ing a formal process model to a real process? In Proceedings of the Seventh International Software Process Workshop. IEEE Computer Society, Washington, DC, 1992. To be published, 1992. 20. Kellner, M.I Software process modeling: Value and experience. SEI Tech. Rev. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pa., 1989, pp. 2254. 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., Finklestein, A., Katayama, T., Osterweil, L.J., Penedo, M.H., Rombach, H.D. ISPW-6 software process example. In Proceedings of the First International Conference on the Software Process. IEE E Computer Society, Washington, DC, 1991, pp. 176-186. 23. Kellner, M.I. and Hansen, G.A. Software process modeling: A Case study. In Proceedings of the 22d Annual Hawaii International Conference on System Sciences, Vol. H--Software Track. IEEE Computer Society, Washington, DC, 1989, pp. 175188. 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 Society, Washington, DC, 1987, pp. 1416. 26. Lin, C.Y. and Levary, R.R. Computer-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 engineering processes. In Proceedings of the First International Conference on the Software Process. IEEE Computer

articleN

Society, Washington, DC, 1989, pp. 188-201. 29. Minsky, N.H. Law-governed systems. Softw. Eng.J. 6, 5 (1991), 285302. 30. Osterweil, L. Software processes are software too. In Proceedings of the

Ninth International Conference on Software Engineering. IEEE Computer Society, Washington, DC, 1987, pp. 2-13. 31. Ould, M.A. and Roberts, C. Modeling iteration in the software process. In Proceedings of the Fourth In-

ternational Software Process Workshop. IEEE Computer Society, Wa,;hington, DC, 1987, pp. 101-104. 32. Penedo, M.H. Acquiring experiences with executable software process models. In Proceedings of the

Fifth International Software Process Workshop. IEEE Computer Society, Washington, DC, (1990), pp. 112115. 33. Riddle, W.E. Session summary: Opening session. In Proceedings of

the Fourth International Software Process Workshop. IEEE Computer Society, Washington, DC, (1989), pp. 5 10. 34. Rombach, H.D. An experiraental process modeling language: Lessons learned from modeling a maintenance environment. In Pro-

ceedings of the Conference on Software Maintenance. IEEE Computer Society, Washington, DC, 1989, pp. 9 5 96. 35. Singh, B. and Rein, G.L. Role interaction nets (RINs): A process description formalism. Tech. Rep. CT-083-92. Microelectronics and Computer Technology Corp. Austin, Tex., 1992. 36. Sutton, S., Heimbigner, D. and Osterweil, L.J. Language constructs for managing change in process

You Need Tree City USA 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 Symposium on Software Development Environments, 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. Programming 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. Metaoperations in the process model HFSP for the dynamics and flexibility of software processes. In Proceed-

ings of the First International Conference 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 International Conference on Software Engineering. IEEE Computer Society, Washington, DC, 1984. 40. Goldman, N. and Narayanaswamy, K. Software Evolution through lterative Prototyping. In Fourteenth

International Conference on Software Engineering (May 1992), pp. 158172. CR Categories and Subject Descriptors: D.2.1 [Software]: Software Engineering - - requirements/specifications; D.2.10 [Software]: Software Engineering-design; 1.6,0 [Computing Methodologies]: Simulation and Modeling-general; 1.6.3 [Computing Methodologies]: Simulation and Modeling --applications; K.6.3 ]Computing Milieux]: Management of Computing and Information Systems--software management; K.6.4 ]Computing Milieux]: Management of Computing and Information 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 Software 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 measurement; process modeling techniques to support process-driven environments; capability evaluation; and process improvement programs. In addition, be maintains researeh interests in the cognitive 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 Definition Project at the Software Engineering Institute (SEI). Kellner has pioneered much of the research on software process modeling conducted at the SEI, and has published several papers on software process issues. Prior to joining the SEI, Kellner was a professor at Carnegie Mellon University, where he established and directed a degree program in information systems. His research interests include software processes, software process modeling, software maintenance, 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 Pulitzer 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 process, process management and improvement, and process modeling and definition. 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

September1992/Vo1.35,No.9/COMMUNICATIONS OF THE ACM