IEEE TRANSACTIONS I270 ON SOFIWARE ENGINEERING, VOL. 17, NO. 12, DECEMBER 1991 Prism -Methodology and Process-Oriented Environment Nazim H. Madhavji and W ilhelm Abstract-Prism is an experimental process-oriented environment supporting methodical development, instantiation, and execution of software processes. This paper describes the Prism model of engineering processes and an architecture which captures this model in its various components. The architecture has been designed to hold a product software process description, the life-cycle of which is supported by an explicit representation of a higher level (or meta) process description. The central part of this paper describes the nine-step Prism methodology for building and tailoring process models, and gives several scenarios to support this description. In Prism, process models are built using a hybrid process modeling language, which is based on a high-level Petri net formalism and rules. An important observation to note is that this environment work should be seen as an infrastructure, or a stepping stone, for carrying out the more difficult task of creating sound process models. Index Terms- Process-oriented environments, process programming and modeling, modeling language and methodology, intended-instantiation, dormant environment, meta life-cycle, meta process, product software process, process fragments. I. INTRODUCTION ECENT work on process programming has marked a new epoch in software engineering. What was perhaps implicit in the minds of many, and in the implementations of systems for programming-in-the-small (e.g., CPS [l]) and programming-in-the-large (e.g., Gandalf [2]) has now been made explicit in recent workshop presentations [3], [4] and Osterweil’s keynote address (51 at the 9th International Conference on Software Engineering: R to externalize these [software] process descriptions, express them rigorously, promulgate them pub“ licly, store them archivally, and exploit computing power to help us in guiding and measuring their execution.” “ process programs might themselves be considered to be instances tion.” of some higher level process descrip- The justification for Osterweil’s strong beliefs, an eloquent response from Lehman pointing out their strengths and weaknesses, and criticisms from Curtis et al. on avoiding the hard Manuscript received August 14, 1990; revised June 26, lYY1. Recom- mended by H. A. Partsch. This work was partially supported by the Natural Science and Engineering Research Council of Canada, and by the German Ministry of Research’s Eureka Software Factory Project (ESF). N. H. Madhavji is with the School of Computer Science, McGill University, 3480 University Street, Montreal, PQ H3A 2A7, Canada. W. Schafer is with the Department of Computer Science, University of Dortmund, P.O. Box 500500, D-4600 50, Dortmund, Germany. IEEE Log Number 9103525. 0098-5589/91$01.00 SchCfer problems of the software process itself, are well explicated in [5]-[7], respectively, and are thus not repeated here. The purpose of this paper is to address the following main concerns: how should process models be developed? what are the components of process descriptions, and how are they related? what is needed for storing them archivally? what is needed for their execution? and what is needed for their improvement? Thus the focus of this paper is on environmental support for process modeling; certainly not on new, tried, or speculative software process models. The problems listed above are significant, because their solutions will pave the way for creating software environments that can be oriented towards the ways developers would like to build and maintain software products. W e refer to such environments as process-oriented environments. In essence, this means that these environments will: subsume the progress already made in programming-in-the-small and in-the-large; respond to the policies for the management of software products as well as human and other resources; support interactions between people, between tools, and between people and tools; adjust to changes in staff, methods, tools, customer demand, budgets, goals, etc.; respond to the individual needs of programmers, managers, projects leaders, etc., in the environment, as to what they need to do, when, and how, without being obtrusive; and other such processes. Through the progress made to date in process-oriented environments, the need for tools to construct, represent, instantiate, and execute software development process models has been well recognized. If, however, these tools will indeed assist in the management of software processes, then the Prism project presses for at least one further important step: explicit, systematic, and automated support for the formalizable fragments of the process of engineering process models. The argument strongly in favor of this meta-level abstraction is that, because the process of engineering process models can be as complex as the process of developing software, the machine monitoring of process-building processes would afford process modelers and managers analogous benefits to those provided to software developers. This meta-level support is explicitly incorporated in the Prism environment architecture. It is important, however, to distinguish between: (a) the meta-level machine monitoring of the process-building process, and (b) the particular set of formalisms and l l l l l 0 1991 IEEE MADHAVJI AND SCHAFER: PRISM-METHODOLOGY AND PROCESS-ORIENTED methods upon which the former is based. In Prism, the former are meta-level process programs and interpretation mechanisms; whereas the latter are the highly incremental Prism methodology for building process models and the accompanying modeling language. In keeping with this theme then, the key or new points of this paper are: 1) the Prism model of a process-oriented environment, which binds together the main functions of the environment; 2) the Prism architecture that captures this model, including the meta-level support, in its various components; 3) the Prism methodology for building and tailoring software process models; 4) example scenarios from the running prototype of (a part of) the Prism environment, which show building, tailoring, and simulating process models; and 5) concepts and primitives of our hybrid, Petri-net, and rule-based process modeling language. Some lesser contributions of this paper include some new terms which help clarify the processes involved in developing, instantiating, and executing process models. Our theoretical approach in this research is that of defining a process modeling methodology and a language based on a combination of high-level Petri net formalism, called Function Nets [8], and production rules [9]. On the other hand, the experimental approach is that of: (a) designing the architecture on top of the UNIX environment, Sunview window manager, and GRAS database [lo] for formally defined graph structures; (b) providing support for the methodology in this architecture; and (c) building a prototype system to get the initial feel for the environment. The next section describes our Prism model of engineering processes. Section III gives the Prism architecture based on this model. Section IV describes the Prism methodology for building and tailoring process models, gives some scenarios to show Prism in action, and describes our process modeling language. Section V makes a comparison with related work, and finally some conclusions are drawn in Section VI. II. THE PRISM MODEL Fig. 1 illustrates the four vertices of our Prism model: Development, Instantiation, Execution, and Methodology. The first three vertices, as described in the literature [4], are to do with the development, instantiation, and execution of processes. These three individual base vertices are therefore now new in this model. On the other hand, what is novel and interesting about this model is that: (a) there is the Methodology vertex, which is meant to imply that certain methods should be used during the process engineering process and that this process is not ad hoc, and (b) the three base vertices are explicitly shown to be interrelated. The Prism model therefore binds together into a concrete form the key issues involved in a process-oriented environment. It is important to note that the “Methodology” vertex in the model does not mean any one particular method; rather 1271 ENVIRONMENT Fig. 1. The Prism model. it is the concept of methodologies-i.e., an invariant-which forms the vertex. Clearly, the described four vertices are the invariants of the Prism model, also referred to as the environment infrastructure [ll]. There are several other items in this infrastructure, such as a process modeling language and its run-time system, an object-management system, a user-interface management system, and an underlying machine, which are not shown in the model, but are of course necessary in the process-oriented environment. The three iterations at the base of the model show the principal cycles involved in the methodical and incremental development, instantiation, and execution of processes. In Prism, these cycles are simulation, initialization, and operation. In the simulation cycle, we construct (a part of) a generic software process model, which may be meant for embedding in a currently running process in the operation phase. A generic model is not constrained by actual parameters, such as company resources, and is based on the user and project requirements documents. This model is then tailored according to the provisions of the software developer and the needs of the software project. At this time, we can experiment with the model in order to ascertain its suitability. The simulation cycle shows the need to remodel and retailor the software process as we get some feel from the dynamic behavior of the process model. As will be described in more detail later in the paper, this cycle constitutes the following nine key steps of the Prism methodology: process requirements, requirements review, specification and design, testing and simulation, design review, identify tailoring, analyze and classify, tailor, and reserve resources. In the initialization cycle, we incrementally instantiate the process model into the desired, but as yet dormant, processoriented environment. Appropriate actual parameters of the establishment are assigned at this stage. The initialization cycle permits us to remodel and retailor the, perhaps partially, instantiated process model. This is sometimes necessary, especially when some of our assumptions about the assigned resources are incorrect. IEEE TRANSACTIONS 1272 Finally, we enter the operation cycle, during which the production of software actually takes place. This cycle permits assessment and improvement of the running software process. This means that: (a) new activities, objects, tools, and human resources can be assigned to the software process, and (b) further modeling and tailoring of the software process may be carried out, as suggested by empirical studies and actual events. Of course, the improvements that invalidate previously made assumptions, observations, and deductions need to be treated with care. Aside from these cycles, it is maintained by the Prism model that: 1) The mechanisms for constructing models and executing processes should support, amongst other things, the lifecycle of software process descriptions. W e refer to the life-cycle of a process description as the metu lifecycle, and the way of creating and executing a process description as the meta process. Many uncertainties which exist during the development and maintenance of complex software make it necessary that this meta process is a highly incremental one. The meta process should be explicitly represented in the environment, just like an explicit representation of the process by which the product software is developed in the operation cycle. In doing so, process modelers and mangers are afforded analogous benefits to those that are afforded to software developers. While providing an umbrella for unformalized metaprocess fragments such as communications amongst human resources, the machine monitoring of the metaprocess gracefully retracts from the mechanical execution of such fragments. Henceforward, a process description for the meta process is called a meta process description; whereas that describing the product software process is called a product software process description. III. THE PRISM ARCHITECTURE Fig. 2 illustrates the architecture of the Prism environment. The three cycles of the meta process introduced in Fig. l-simulation, initialization, and operation-are shown to be supported by the three components of the same names in the Prism architecture. In addition, there are three interfaces-namely, user, tool, and objectbase interfaces-through which, respectively: the users of the environment, according to their roles in the software project, interact with the components; appropriate tools are invoked, by the components, in the three cycles of the meta process; and the tools access the objectbase in order to store and retrieve information as required in each of the three cycles. Below, we discuss the architecture components and the use of the GRAS (Graphs and Relations in an Associative Storage) [lo] object management system. Our current tool base is the UNIX tool-box. l l l ON SOFIWARE ENGINEERING, VOL. 17, NO. 12, DECEMBER 1991 pEFzky,;) tool speclflc data (performance, Fig. 2. The Prism architecture. A. Simulation, Initialization, and Operation Components The meta processes carried out in the simulation, initialization, and operation components are called, respectively, the simulation meta process, initialization meta process, and the operation meta process. Each of the three components consists of two basic items: (a) an explicit representation of an appropriate meta process description, and (b) an interpreter for this description. In addition, the operation component contains a product software process description and its interpreter. Both meta process and product software process descriptions are represented in a language called FunSoft, which is based on Function Nets. One of the main features of this language is dynamic binding of tools to net transitions, called “agencies.” The details of the syntax and semantics of FunSoft and its interpreter can be found in [12]; some scenarios of software process design using FunSoft are presented in Section IV-A.l. The execution of the meta process descriptions coordinates various activities. For example: (i) the simulation meta process assists in process development during the building, tailoring, and running of process models; (ii) the initialization meta process oscillates back and forth between the instantiation of a tailored model (with specific parameters) and the development of the model; and (iii) the operation meta process starts the execution of the product software process description (which in turn initiates the management and improvement of the product software process), awaits the completion of the product software process, and finally, it itself also terminates. These meta processes are based on the Prism methodology, which is treated in more depth in the subsequent sections. From the above, one can clearly note that in Prism, even those who are responsible for process models and product software processes are destined for a planned environment-not only those who are directly involved in the development of MADHAVJI AND SCHAFER: PRISM-METHODOLOGY AND PROCESS-ORIENTED the software product. This is an important feature of Prism which to our knowledge is not present in other published architectures. 1) Meta Process Programs: At least at the moment, it appears that the linguistic features for describing meta processes are the same as those for describing product software processes. Thus with only a little overhead in the Prism architecture, it is possible to provide the same kind of support at the metal level as that which is provided at the software production level. A meta process description has the following notable concepts, some of which have a graphical notation: (a) object types, (b) activity types, (c) activity guards, (d) relations between activity types, and (e) exception handling mechanisms. In order to interpret such a description, the textual parts are incrementally translated into our version of Function Nets. Object types in the language define, textually, the structure of objects in the objectbase and their interrelationships. Example objects include requirements for process modeling, design of a process model, model review report, and the like. For this purpose, we have designed a data definition language, incorporating: (i) the type construction mechanisms of Modula-2 [13], and (ii) an inheritance mechanism (without Smalltalk-like dynamic binding) denoted by classes and subclasses. On the other hand, activity types, activity guards, relations between activity types, and exception handling mechanisms enable one to describe the central part of a process model. An activity type describes textually: (i) a particular activity, and (ii) its pre- and postconditions. The semantics associated with this activity is given by either: (a) the tool carrying out this activity, or(b) a refinement of this activity into subactivities. In the case of semantics-by-tool, the system can inspect the preand postconditions associated with the tool in order to detect certain conditions (e.g., erroneous states) that the objects might be in and take appropriate actions. An activity guard defines, textually, a condition under which an activity can take place. Similarly, a relation between activity types defines the order in which activities are going to take place. This is specified graphically in the form of function nets. The exception-handling mechanism takes the specified action upon the occurrence of an exception. Example actions that can be specified are replacement of a subgraph with another one, tracing of the activities that raised the exception, invocation of a tool to report the occurrence of the exception, etc. 2) The Interpreter: In interpreting function nets, the interpreter executes the pre- and postconditions of the various activities and invokes the specified tools. As there may be several activities which might be permissible in a given context, the interpreter presents an agenda to the user. The mechanism for gathering the agenda has been built into the interpreter, although there is an alternative scheme of leaving it in the system library from where the process designer can use it as and when desired. The former scheme has the benefit that the modeler does not have to be concerned with this mechanism during the modeling activity; whereas the latter scheme has the benefit that the modeler has an explicit control over when to provide this service. 1273 ENVIRONMENT In order to access tools from the tool base, we use UNIX shell scripts, which are bound to appropriate activities within function nets. This is similar to the tool envelopes of MARVEL [14]. Shell scripts have the benefit that: (a) tool-specific parameter information, obtained from the user, can be passed on from the process model to the tools, and (b) feedback information (e.g., successful or unsuccessful compilation of a module) can be passed from the shell scripts to the process model for further analysis. The interpreter, called FUN, was originally obtained from the Technical University of Berlin [ 1.51and is written in Simula [ 161. W e have since modified it to provide, among other things, the binding of function nets to shell scripts. In addition, prior to the design of our graphical language FunSoft, we implemented a graphical editor for direct entry of extended function nets. B. The Object Base The object base plays an important role in the Prism architecture, as information needed or produced during the simulation, initialization, and operation cycles is stored, retrieved, and manipulated by accessing the object base. Such information includes: fragments of software process descriptions; tool specific data, such as their functionality, performance, reliability, portability, compatibility with other tools, etc.; personnel data; and software components and documents. This information is highly inter-related and forms complex directed attributed graphs. The nodes in the graphs correspond to object and activity types and their instances. The edges represent relations between types and instances, between objects and activities, and so on. In order to have an efficient access to the above information, the graphs are stored in the nonstandard data base system, GRAS [lo], dedicated to the manipulation of complex attributed graphs of arbitrary size. GRAS, which was developed within the IPSEN programming environment project [17], provides an interface for the creation and deletion of graphs, nodes, and edges. In addition, GRAS permits associative queries for browsing among graphs. On top of this GRAS interface, we have implemented a layer of higher level primitives to store/retrieve components of a process model, such as objects, activities, guards, etc. In other words, we have adapted GRAS to a specific software process domain. This high-level interface is used by the Prism tools, such as the FunSoft editor. IV. PRISM IN METHODICAL ACTION In this section we discuss the three meta cycles in Prism: simulation, initialization, and operation. Example scenarios are given for the first of these cycles, in the context of the Prism methodology, and key issues are discussed for the last two cycles. A. The Simulation Cycle This is the cycle when process models are developed and tested. It is worth reiterating here that the developed models are generally for inclusion in the currently running software process in the operation cycle. In any case, this task should IEEE TRANSACTIONS 1274 ~~ read, comment, 1 STEP 4 - analyse requirement Do Testing & Simulation get process model prepare test data test and debug simulate 4 STEP 5 Do Design Review - see STEP 2, but for design - if not OK goto STEP 3 Fig. 3. Process-building methodology. not be ad hoc or taken lightly, since any weaknesses in the resultant process models are likely to show up in the way software is actually produced in the operation cycle. Below, we discuss the steps involved. 1) Building a Model: In Prism, the key steps involved in building a generic process model are (see Fig. 3): (a) requirements engineering, (b) review of the requirements gathered, (c) specification and design of process fragments, and (d) review of specification and design. In what follows, we discuss: (i) the assistance from the interpreter while executing the meta-process description based on the Prism methodology, and (ii) the details of the methodology itself. Step 1 -Requirements: The requirements for developing a process model should not be intuitively produced by the modeler. Ground work done by the customer (reported in the user requirements document) describing what the customer needs, and ground work done by the software developer (reported in the project requirements document) describing what the project needs in order to satisfy the customer requirements, should provide much of the ammunition needed by the modeler. It should be noted, however, that these documents, especially the project requirements document, are not a one-time activity. Since project goals can change and perhaps more ON SOFTWARE ENGINEERING, VOL. 17, NO. 12, DECEMBER 1991 seriously, the product software process can change (e.g., through improvements), the project requirements document evolves with time. The meta-process interpreter assists in this process by making available to the modeler the appropriate browsing, querying, and requirements collection tools, together with the names of the required documents, so that he/she can access these documents from the objectbase and engineer processmodel requirements. These requirements documents should provide the modeler with the details of the technical and managerial processes which are being, or will be, carried out during the operation cycle of the environment. Some example questions that he/she needs answering from these documents are: which activities of the software life-cycle are to be supported? what management processes provide infrastructural support to, and control, the technical processes? (Note that the how of this and other questions should be answered during the model’s design stage.) What team structure is suited to various parts of the project? What approach is to be taken in the development of the software product; e.g., prototyping versus rigorous? What different software process iterations are required? What are their pre- and postconditions ? Which parts of the software process can be carried out in parallel? Which parts require human intervention and hence are nondeterministic? What kinds of tools are associated with these activities? What are the resulting document types? The findings of this step should yield a structured process model requirements document, preferably in the objectbase, and it should clearly state the properties of the process model that is to be built. As much as possible, this document should avoid the specifics, and instead capture the generic properties of the software process model so as to increase the chance of reusing the resulting process model. Again, note that the process model requirements document also evolves with time in the operation cycle, since changes to the running software process are incorporated incrementally. Step 2-Requirements review: The meta-process interpreter requests for a review group to be set up, and eventually informs the reviewers of what is required of them. In order to facilitate the review process, the meta interpreter makes several tools such as an editor, browser, report generator, and query tool available to the review group. This group then proceeds to read, analyze, and comment upon the model requirements document. The modeler should then be informed about his/her participation in the review process [18]. This process should generate a review report, which is then released to the modeler and others concerned. The review report may signal a revision of the requirements engineering activities, that should eventually be satisfied. It should be clear from the foregoing description that the meta-process interpreter plays a considerable part in guiding the modeler and assisting in menial and mundane tasks of providing administrative support. The basic point here is that the meta-process knows about: the “tons of tools” in the tool base, which tool is suited to what activity, compatibility between tools, who is responsible for what, what objects are needed by whom and when, what to do when an exception MADHAVJI AND SCHliFER: PRISM-METHODOLOGY AND PROCESS-ORIENTED Generic Model ENVIRONMENT project development plan DEVELOPMENT for distribution Fig. 4. plans An abstract software pmducts process fragment. occurs, and much, much more. The modeler, on the other in order to synthesize new fragments. The static semantics of hand, may not, and if he/she thinks otherwise, then in many the synthesized fragments can be checked incrementally during cases he/she may be wrong. Thus it is one important feature the construction process. This issue, however, is currently of the meta-process interpreter to free the modeler from these being investigated. Below, we illustrate what is possible in mechanical tasks and thereby enable him/her to attempt hard our current prototype system. An example of designing: Fig. 4 shows an abstract fragproblems of creating sound process models. Both in the preceding and succeeding steps of the method- ment describing Schwartz’s SEM iteration model [20] for manology, it would be misleading to assume that any given step aging software. This fragment shows planning, development, would restrain the modeler as in a pure waterfall-style life- and distribution activities, with a central repository for softcycle model. The process of constructing software process ware project and personnel information. The iterations show models involves a high degree of risk, largely due to their how one activity can influence other activities in the model. Fig. 5 is a refinement of the development activity in Fig. 4, many associated uncertainties. Thus this meta-process necessarily calls for a flexible and incremental approach. and together the two fragments (Figs. 4 and 5) form a hierarStep 3-Specification and design: W e can now shift chy. The fragment in Fig. 5 shows a simple iterative model our focus from the assistance provided by the meta-process of the familiar design, code, compile, link, and test cycle. interpreter to the “nuts and bolts” of the design produced The boxes represent activities; circles represent objects; and by the modeler. The key concepts at this level are: (a) ab- the arrows indicate control and object flow. Other fine-grain straction and refinement, (b) identification of process modules, details such as activity guards, pre- and postconditions of an (c) specification of module interface, and (d) design of process activity, and the structure of objects can be made visible with module bodies. appropriate simple textual tools by clicking with the mouse at Abstraction and refinement are well known from the pro- the desired points on the net. The following annotated code gramming literature. The identification of major process mod- relates to the Edit-code and Compile - link activities: ules is also reasonably straightforward. What is not so clear at this stage is the precise specification of process module ATTRIBUTES interfaces, since the concept of a process module is not as designed, coded, compiled; well founded as in modular languages such as Modula-2. W e (*module attributes *) are therefore pressing for a more general notion of process OBJECT-TYPE fragments, of which a module is one such fragment. module= (* Types ofmodules *) The idea of process fragments is based on our previous TUPOF (module-design: design, module-code: code); work on typed program code fragments, called fiagtypes [ 191, with an intent to formalize process fragments. The basic design = (* Description of a design idea here is that if it is possible to define different types of module *) process fragments with respect to their structural properties, TUP OF (name : string; then operations to manipulate process fragments can be defined designed-by : person; IEEE TRANSACTIONS G Test Put in the repository and release for distribution 0 Fig. 5. ‘* software products software products A refined process fragment designed-on, date-of-last-access : date import-design, export-design, body-design: string): code = (*Description ofa code module *) TUPOF (name; contents : string; lines of code : integer); ACTIVITY-GUARDIFUSER-REQUEST (Edit-code) THEN-Edit code END; (*Edit codeisactivatedonly upon userrequest *) ACTIVITY-TYPE Edit-code : $X:module --f $X; PRECONDITION: $X IS designed; POSTCONDITION: $X IS coded; SEMANTICS: vi; (*Module$Xis editedusingvi. pre- andpost-conditions are specified *) compile/link: $X:module+ $X; PRECONDITION: $X IScoded; POSTCONDITION: $X IS compiled; SEMANTICS: cc; The process fragment in Fig. 5 shows that: (a) the finished products (see bottom part of the figure) are put in the repository ON SOFTWARE ENGINEERING, VOL. 17, NO. 12, DECEMBER 1991 and also sent for distribution; (b) the change requests for products (see also Fig. 4) are used to prepare the next versions of the product; and (c) it is generic, i.e., it does not consider any practical company details such as specific developers, tools, objects, etc. It is, however, possible to run this generic model on the net simulator in order to test and validate the design. Step 4-Testing and simulation: Once we have designed (or tailored) a process fragment, it should then be tested and validated so as to increase our trust in the designed fragment. W ith the use of appropriate tools, we can prove certain static properties (such as deadlocks, starvation, etc.) and observe the dynamic behavior (frequency counts, object flow, delays, etc.) of the software process. This may lead to remodeling (Step 3) (or retailoring, Step 6: see below) the process fragment. While we can reuse research results from the field of testing, debugging, and validating sequential and concurrent software [21]-[24], there is one important difference that should be noted: in concurrent systems, the monitoring of time critical regions can be difficult [25], since the introduction of a monitor can change the behavior of the system. It is pleasing to note that this predicament does not generally carry over to the monitoring of software processes, since the time scales involved are usually much larger! Fig. 6 shows a screen dump resulting from the simulation of the edit/compile/test cycle in Fig. 5. (The layout has been edited for this presentation.) There is static information about the activities (see AGENCY in the large window) and objects (see CHANNEL in either window), dynamic information (see TRACE in the large window), and statistics about activities, objects, object flow, etc. The first two lines of the large window tells us the allotted time units for each activity: compile = 3, edit = 20, test = 15, etc., and the method of accessing objects (e.g., LIFO, FIFO, etc.), channel capacities, where the objects are initially, and so on. It is assumed here that the actual test data used is based on empirical studies from previous projects. This particular concern is outside the scope of this paper. The matrix (of channels versus agencies) in the large window is another representation of the function net being simulated: i = input, 0 = output. The trace (see under TRACE) shows which objects were at which channel at what time during the simulation. In a software process, this information is useful for understanding which activities are alive for what period of time, how long it took to carry out a certain activity, etc. Thus human and computing resources can be redirected as necessary. The agency statistics show individual times for each activity (9.0, 60.0, 45.0) and the total time (78.0) from which we can infer that some of the activities must have been carried out in parallel. The load statistics for channels show how big (min., max., and ave.) the waiting queues were for certain activities. In the software process, this can help identify bottlenecks in the system, less critical activities, and so on. In the small window in the figure we see statistics about token (or object) flow and delays in the system. In the software process, this can suggest retraining of staff, switching to higher performance machines, etc. Finally, there is the overall MADHAVJI AND SELS: SCHiiFER: PRISM-METHODOLOGY AND PROCESS-ORIENTED 1277 ENVIRONMENT LIFO:CO~~ : A T R I X hannals ------- Functionnet: Standard Deviation I===-= 1 Deviation R A C E (FIRING - SEQUENCE) Time Ghan.-> 1 2 3 4 co ed en rt As==Y Initial = 0 0 0 3 edit 20.000 edit max. . . 63.000 78.000 imulation compile test terminated plllp Job H ANlPEL Cap. 0mp~md di-mod 1 AGERCIES due to DEAD 15 2 : load 49O 0' lWT, - STATISTICS: Activities .GEACY ame + channel - STA!l!I.9TICS : LOAD kfin &IX Avg standard b Deviation 0 7 0.0 0.0 0 50 0.0 0.0 A&iv-Tim mln')',avg'*',max'-' 0% -------------. Fig. h. Process net (MODEL) statistics, which give the maximum (64%) minimum (0%) and the mean (49%). From this one can deduce how much more resources can be added to or removed from the net. Following the simulation activity, the resultant process fragment should be reviewed. This is shown as Step 5 in the methodology. 2) Tailoring the Model: Tailoring a model is not the same as designing a generic model. The latter is based on the process model requirements document, with possible references to the user requirements and project requirements documents, and without consideration of any facts and figures of the establishment concerned. On the other hand, tailoring is based on the generic model and some hard facts from the software developer. In addition, tailoring is not applicable only to the initial design of the process model, but also to a generic model of a software process fragment any time from the inception of the process description up to and including its execution. Fig. 7 describes the key steps involved in the tailoring process: (a) identify if tailoring is necessary, (b) analyze and classify the tailoring to be done, (c) tailor and test the model, and (d) request for the reservation of resources. In the elaboration below of these tailoring steps, we do not discuss Load simulation the role of the meta-process interpreter, but instead we focus on the tailoring methodology itself in Prism. Step 6-Zdentifi: The first step of the tailoring process can be answered by matching what the model needs against the constraints of the company. The former is described in the process model requirements document; whereas the latter can be found in the managerial, personnel, tool, and project objectbase. To aid in this process, query tools should provide information about: (a) the availability of the technical and managerial staff, such as various team leaders, specifiers, designers, implementors, testers, reviewers, documenters, technical support staff, managers, policy makers and planers, market research staff, customer relation staff, distributors, etc.; (b) the projects in which these various people have worked before and their experience in the technical, managerial, and application domains to which the software project is related; (c) the availability of the required software tools; (d) tool evaluations with respect to usability, performance, reliability, portability, etc.; (e) the compatibility of a given tool with other tools used in a certain phase; (f) the structure, type, and relationships among the components of the product to be developed; and (g) project milestones; etc. IEEE TRANSACTIONS 1278 1 STEP 6 yeniify , - get generic model (model reqs dot) get company facts (objectbase) identify tailoring required? b I /I k/ I I 1 - establish entity produce resource Fig. 7. types (cf. request actuals) document Process-tailoring methodology Jeffery and Basili [26] give an excellent characterization of project resources that would be particularly useful during the tailoring process. Their TAME resource data model has a four-dimensional view (resource type, description of consumption, incurrence, and availability) and is divided into two segments (resource types and resource use). These are further classified into various relevant lower level elements. Given such a structure, a suitable database system with capabilities to store/retrieve numeric values along with reasons for these values can be helpful in: (a) retrieving facts in order to tailor current process model, and (b) storing feedback information resulting from process analysis. Step 7-Analyze and class&: If the litmus test in the identification phase is positive, then the mismatches should be carefully analyzed and then classified into: activity types, tool types, object types, roles, and for complex changes, subparts of the model. W e give below some example mismatches and their possible consequences: As is often the case with software engineers, a lack of expertise in the applications domain for which the software is to be built may suggest reshaping the process model to include a learning and training phase. On the other hand, the availability of excellent prototyping tools and personnel may suggest, at least for some risky projects, flexible and experimental process models in the first instance, followed by a rigorous model. The model assumes powerful report generators, but the company has only rudimentary ones, and possibly not compatible with the main flow of the modeled process. This model should then change in order to make do with what the company has. A counter example is that the company has a variety of tools, and the model leaves open as to how exactly certain documents are produced. This gives the company a chance to, say, use development compilers during coding and testing, which are later to be l l ENGINEERING, VOL. 17, NO. 12, DECEMBER 1991 replaced with optimizing ones. If a training phase is added in the process model, then perhaps new roles of teachers and learners and new tool, activity, and object types may also be required. Often there are financial and other business decisions made which affect human and computing resources. These managerial decisions take place concurrently with software planning activities, and hence the task of tailoring can become quite difficult. While the above examples are not exhaustive, they clearly illustrate that a single mismatch can easily affect a number of activities, tools, roles, objects, etc., in the generic model. Therefore a detailed understanding of each mismatch is particularly important for successful tailoring. Step 8--Tailor: Having done the preparatory work, changes to the generic model involve establishing appropriate activities, roles, tools, objects, quantities of these, and their relationships which are possible in the company. These changes should then be validated through the simulation exercise (Step 4). However, it is important to realize that even at this stage, the changes should be kept as much as possible at the type level than at the instance level so as to simplify any changes later on. For example, the “editor” tool-type permits various specific editing tools such as “vi,” “Module-2 editor,” etc., to be allocated, depending on the likes and dislikes of the programmer to be employed; the “design specifier”-type allows the flexibility of which particular person will play that role; and so on. But it is quite clear that this particular activity of the tailoring process is driven by the actual resources the company has (or will have). If, for example, there is an intention to have person (or tool) “A” in the software process, then the choice and ordering of associated activities, tools, objects, relationships, etc., may be significantly different from that if person (or tool) “B” were employed. This, intended binding of desired actual resources is what we call here intendedinstantiation of the process model. Intended-instantiation is not an actual assignment of resources, also called instantiation [4], which happens at a later stage. W e shall see the role of intended-instantiation in Step 9, following the example below. Let us make an assumption An example of tailoring: which we can then use in tailoring the process fragment of Fig. 5. Assumption: the company policy is that the change requests for products should affect both the current and future versions of the product. The generic model in Fig. 5 caters for future versions only, and so we analyze the impact of this policy on the technical processes. This analysis suggests that appropriate change requests should somehow be fed into the current development activities so that the changes can be accommodated. The tailored version, shown in Fig. 8, incorporates the following key changes: (a) change requests for products are classified into current and future changes; (b) current changes are fed into a new activity called “Validate changes”; (c) modules already designed but affected by the changes are sent for redesign; and (d) similarly, affected code is recoded, based on the task descriptions from the design, test, and future version activities. l l STEP 7 Analyse and Classify analyse generic model - classify tailoring ON SOFTWARE MADHAVJI AND SCHAFER: PRISM-METHODOLOGY AND PROCESS-ORIENTED 1279 ENVIRONMENT modules to redesign than es affec ?mg current “WSIO” project repository I Put in the repository and release for distribution 1 I- 0 I sortware products software products Fig. 8. Tailored This tailored version should also be run through the simulator (Step 4). Step 9-Reserve resources: Following the tailoring activity, a reservation request for the required set of resources should be filed with the responsible party. This is not a commitment of resources by any means and if the request is not fulfilled, then this may lead to further tailoring (Steps 6-9). On the other hand, all the requests that are granted should be recorded in the objectbase so that this information is made immediately available to other interested parties. A resource request should be based on intendedinstantiation, which should record the required or desired resources in some order of priority, together with the reasons for their choice, in the tailored model itself. It then becomes a relatively simple mechanical task at producing a resource request document. This document should then be made available to the appropriate managers for the commitment of resources. There are basically two main methods of filing a resource request: static and dynamic. A static request means that for the given tailored process model, all the required resources are requested up-front, before the process is instantiated. On the other hand, a dynamic request means that resources are requested during the execution of the software process as their need becomes clear. The static method can lead to a wastage of resources, whereas the dynamic method can promote resource sharing among different software projects. One can draw an process fragment analogy with the resource allocation schemes in the field of operating systems [27]. In practice, it is the dynamic scheme which makes sense in software development. The primary reason is that, in general, it is not possible to foresee all the resource needs up-front for a large software project. For example, the number of programmers required during the coding phase of the software project may not be known until software has been designed to some extent. Of course, due to the dynamics of the software project, the dynamic scheme can be nontrivial. The dynamic scheme implies that for a given software project, there will be a series of resource request documents which will be produced at different times during software development. B. The Initialization Cycle This cycle is relatively simple, since we are expected to have done the ground work: the process model (or part thereof) has been tailored and tested, and the requested resources have been committed. Primarily, the intended-instantiated process description gets actually instantiated, meaning that intended resources such as tools, people, activities, objects, constraints, conditions, relationships, etc., get assigned to the software process. Of course, instantiation of a tailored process fragment does not imply actual execution of this fragment in the context of the running production environment. On the other hand, an executing fragment implies that the process fragment has been IEEE TRANSACTIONS 1280 ON SOFTWARE ENGINEERING, VOL. 17, NO. 12, DECEMBER 1991 Management of the Operation Meta Process Product Software Process Time -w Software Development Phase Post Project Analysis Product Developement Product Management Fig. 9. The operation cycle. instantiated. Thus an instantiated fragment (or environment) which is not as yet running is what we call a dormant fragment (or environment). Two of the important points about the process of instantiation are that: (a) it is a mechanical task, since we have already recorded our intention of using certain desired actual parameters-which tool is to be used for what activity, who is playing what role, what document should be delivered when, what design procedures are to be followed when, say, the chief designer is not available, etc; and (b) it is an incremental task, since, as described earlier, the request for resources is usually made dynamically during the operation cycle. The “fact of life” is that even after instantiating (a part of) the process model with a particular resource, we may need to iterate over earlier steps, hopefully only tailoring (Steps 6-9). This can happen when we find out some new facts about the committed resource. For example, person “X” assigned to work on the project has suddenly decided to leave the company; the committed tool “Y,” while acceptable in general, does not interface well with other tools in the environment; or the allocated workstation “Z” supports an application system which inherently captures a substantial part of the software process. C. The Operation Cycle Fig. 9 elaborates on the operation cycle (see Fig. 1) in which the product software process is interpreted. At this time, we are primarily concerned with: (a) the development and management of the product; and (b) the management of the product software process. The first of these has a life time spanning the software development phase only, and during this period, tool envelopes invoke: user I/O communication tools, specification, design, editing, implementation, testing, and debugging tools; object management, configuration and version control tools; and other such tools. The second of these, however, has a life time which additionally encompasses the post-project analysis phase. In the development phase at the appropriate steps, the management of the product software process includes incremental collection of prescribed data by process monitoring tools, validation of such data, and process analysis before providing repeated feedback to the current project. This feedback may result in remodeling and retailoring parts of the software process (Steps l-9), instantiating some new items in this process or even project termination in the case of complete failure. The development phase is then followed by postproject analysis of current practices, problems, findings, etc., in the present software project. Thus there is a built-in mechanism in the operation phase for recommending improvements for future projects. In [28], Basili and Rombach describe their five-step processimprovement methodology. The first three steps deal with choosing appropriate process models, methods, and tools; whereas the last two steps deal with performing software development, gathering data, providing feedback, and making recommendations. Similarly, Crawford and Fallah [29] describe a software process audit procedure based on the following three steps: (a) characterize the existing process, (b) identify project strengths and weaknesses, and (c) provide recommendations. It is clear to see the complementary role of these works within the framework of Prism. For example, during the simulation cycle (see Fig. 1) there is a great need for sound process models, which can then be tailored according to the selection of appropriate methods and tools. Also, in the MADHAVJI AND SCHAFER: PRISM-METHODOLOGY AND PROCESS-ORIENTED operation cycle, we have described the need for repeated project feedback and future recommendations. Hence process improvement tools and methods would soak up a considerable burden of building new Prism tools for process, method, and tool evaluation and would simplify the design of some parts of process models. V. COMPARISONS WITH RELATED WORK Process programming is currently a subject of much debate, as evidenced by the proceedings of several major conferences [3], [4], [30]-[32]. While there are some concerns expressed on this subject [6], [7], the solidifying theme is that of process instantiation and execution. Much else is still open to debate: process modeling languages, environment architectures, process engineering tools, etc. In this section we compare our early work to that of others from the standpoint of: (a) environment models and architectures, (b) methods of building process models, and (c) process modeling languages. Perry and Kaiser (331 have classified environments according to scale: individual, family, city, and state. In their classification, all environments fit under either the first or second class, except ISTAR [34] and Inscape [35], which fall under the city class. Two orthogonal characteristics of each class are: (a) in terms of scale-construction, coordination, cooperation, and commonality; and (b) relationships among components-mechanisms, structures, policies, and high-order policies. While Prism is still in its infancy, it has a potential to grow into the city class, if only for the reason that policies enforcing certain methods of software development and management may be incorporated into product software process models. (Notice that the Prism architecture also allows for this at the meta level.) This is, in fact, one of the advantages of all process-oriented environments; i.e., to be able to separate environment infrastructure from the variant parts. In Prism, the upward growth is likely to come from two main sources: (a) explicit support for dynamism during the meta cycles in remodeling and retailoring parts of process models, and (b) from the feedback information obtained during the operation cycle about the software process. In comparison to the Prism model (see Fig. l), it is clear to see that most process-oriented environments have only three individual vertices-namely, Development, Instantiation, and Execution. Also, it is not clear to what degree there is free movement among these three vertices, except perhaps in rulebased systems such as MARVEL [14]. In Prism, it is planned right from the beginning to have a highly incremental model, meaning that even a part of a process may be modeled, instantiated, and executed. In the area of architectures, work is centered around process execution. Although the forms of architectures may be different, there is a general consensus on the environment infrastructural support: (i) a run-time system, and (ii) managers for a user interface, database, tools, and the software process. For example, in MARVEL, rules in the database are used to model a software process, and pre- and postconditions in the rules govern sequencing, concurrency, and nondeterminism in ENVIRONMENT 1281 the software process. On the other hand, TRIAD [36] has a single component which holds a customized representation of a software process, in addition to its infrastructural support. In contrast, there are three architectural components (simulation, initialization, and operation-see Fig. 2) in Prism which correspond to the three meta cycles of the Prism model. On the methods scene, it appears that with much excitement in the debates over process programming the ways of building process models has received little attention thus far. Most efforts focus directly on the design level, although at the time of this writing it became apparent that Boehm and Belz [37] had applied process programming to the spiral model. In this paper we have described at the meta-process level the use of requirements, review procedures, specifications, and so on in building generic models, and of the tailoring steps in turning generic models into specific ones. W e have also shown simulation as a way of getting some feedback from the process model, and advocate process improvement methodologies [28] during the operation cycle. Finally, in the language arena, TRIAD uses a conceptual modeling language and incorporates the concept of hierarchical communication sequential tasks. MARVEL, as mentioned earlier, uses a rule-based formalism, as does SPM in the behavioral approach [38]. The latter has messages, in addition, as a means of communication and synchronization among activities. GENESIS [39] also uses a rule-based formalism for the detection of inconsistencies in the activities of the user. In Prism we use a hybrid notation-that of function nets and rules. These are then mapped onto the underlying net representation. Thus all pre- and postconditions, activity guards, exception handlers, etc., are in the net form in Prism. The need for a hybrid approach or multiple paradigms in a processmodeling language has also been suggested by Osterweil [40], and Taylor et al. [ll]. Finally, PML [41], from the IPSE 2.5 Project, is an object-oriented conceptual modeling language. A process model in PML includes a network of classes (e.g., role, interaction, action, entity, and assertion), whereby specialization allows subclasses and inheritance allows the use of definitional properties of the higher class. In such a network, the flow of control is determined by assertions about inter-role and intrarole states. VI. CONCLUSIONS In this paper we have presented several key aspects of the Prism environment. One, the Prism model, which binds together the main functions of a highly incremental processoriented environment: methodical process modeling, instantiation, and execution. Two, the Prism architecture, which captures this model in its various components. An important feature here is that there are explicit representations of metaprocess descriptions in order to assist in the development of product software process models and in their instantiation and execution. Three, the nine-step Prism methodology for building and tailoring software process models: Steps 1 to 5 of this methodology cover the requirements to design activities, whereas Steps 6 to 9 cover the tailoring activity. Following this, in the initialization cycle, process instantiation is a IEEE TRANSACTIONS 1282 straightforward incremental task, and in the operation cycle there is continuous product software process improvement and postproject analysis. Finally, four, a hybrid process modeling language which is based on function nets and rules. An important observation to note is that this work should be seen as an infrastructure, or a stepping stone, for carrying out the more difficult task of creating sound process models. It, in itself, is not expected to improve significantly the software development process! In this respect, we share the concerns addressed by Lehman [6] and Curtis et al. [7]. On the other hand, we expect that improved process models (and methods and tools) will augment the power of software managers and developers in much the same way as improved tools and procedures have augmented the power of engineers in the conventional disciplines. What are therefore urgently needed, besides infrastructural support, are empirical studies for evaluating and improving existing processes, methods, tools, and environments. Some such work is cited in [7], [42], [29], [43]. Our work on software processes continues in several areas, including the design of process modeling languages, process modeling methodologies, managing changes in software processes [44], reliability of software processes [45], process understanding [46], quality process models [47], and process evolution [48]. ACKNOWLEDGMENT The authors are grateful to M. Dowson, L. Osterweil, H. Schippers, H. Weber, and the anonymous referees for their comments on the earlier drafts, which have helped improve this paper. ON SOFTWARE ENGINEERING, VOL. 17, NO. 12, DECEMBER Conf (ESEC ‘89) (LNCS 387), Ghezzi and McDermid, Eds. Berlin: Springer-Verlag, 1989, pp. lOO- 117. [I31 N. Wirth, Programming in Modula-2, 3rd ed. Berlin: Springer-Verlag, 1985. [I41 G. E. Kaiser and P. Feiler, “An architecture for intelligent assistance in software development,” in Proc. 9th Inc. Conf on SofhYare Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1987, pp. 180-188. u51 R. Pallman and H. Truemmner, “Design and implementation of a program generator based on function nets,” Univ. Berlin, Diploma thesis, Aug. 1984 (in German). [I61 G. Lamprecht, Introduction to the programming language SIMCJLA. Vieweg: Braunschweig, 1982 (in German). [I71 G. Engels, M. Nagl, and W. Schlfer, “On the structure of structureoriented editors for different applications,” in Proc. ACM SIGSOFTISIGPLAN Software Eng. Symp. Practical Software Development Environments, (ACM SIGPLAN Notices), Jan. 1987, vol. 22, no. 1, 190-198. D. iI81 L. Parnas and D. M. Weiss, “Active design reviews: principles and practices,” in Proc. 8th Int. Conf on Software Enz. (London). Aug. 1985, pp. 132- 136. [I91 N. H. Madhavji, “Fragtypes: a basis for moeramming environments,” IEEE Trans. Software Eni., vol. 14, pp. iS-y7, Jan. 7988. PI D. P. Schwartz, “Software evolution manaeement: an integrated discipline for managing software,” in Proc. 9th Inc. Conf: on Software Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1987, pp. 388-398. PI W.R. Adrion, M.A. Brandstad, and J.C. Cherniavskv, “Validation, verification, and testing of computer software,” Computmg Surveys, vol. 14, no. 2, pp. 159-191, June 1982. PI R. N. Taylor, “knalysis of concurrent software by cooperative application of static and dynamic techniques,” in Software Validation, H. L. Hausen, Ed. Amsterdam: Elsevier Science, 1984, pp. 127- 137. J. ~231 Fagerstroem, “Design and test of distributed applications,” in Proc. 10th Int. Conf on Software Eng. Singapore: IEEE Computer Sot. Press, 1988, pp. 88-92. [241 R. H. Carver and K. C. Tai, “Reproducible testing of concurrent programs based on shared variables, ” Proc. Distributed Syst., pp. 428-433, 1986. [251 C. V. Ramamoorthy, K. H. Kim, and W. T. Chen, “Optimal placement of software monitors aiding systematic testing,” IEEE Trans. Software Eng., vol. SE-I, pp. 403-411, Dec. 1975. PI D. R. Jeffery and V.R. Basili, “Validating the TAME resource data model,” in Proc. 10th Inc. Cant on Software Enp. Los Alamitos. CA: IEEE Computer Sot. Press, 1988, pp: 187-201’: [271 P. J. Denning, “Virtual memory.” ACM Comout. Survevs. vol. 2. pp. 153-189, 1970. P81 V. R. Basili and H. D. Rombach, “Tailoring the software process to project goals and environments, ” in Proc. 9th Inc. Conf on Software Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1987, pp. 345-357. ~291 S. G. Crawford and M. H. Fallah, “Software development process audits-a general procedure,” in Proc. 8th Inc. Conf on Software Eng. (London), Aug. 1985, pp. 137-141. I301 Proc. 9th lnt. Conf on Sofiware Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1987. [311 Proc. 10th Inc. Conf on Software Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1988. 1321 Proc. 11th Int. Conf: on SofhYare Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1989. [331 D. E. Perry and G. E. Kaiser, “Models of software development environments,” in Proc. 10th Inc. Conf on Software Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1988, pp. 60-68. integrated project support environment,” [341 M. Dowson, “ISTAR-an IEEE Software, pp. 6-15, Nov. 1987. D.E. Perry, “The Inscape environment,” in Proc. 11th Int. Conf: on [351 Sofnyare Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1989, pp. 2- 12. [361 J. Ramanathan and S. Sarkar, “Providing customized assistance for software lifecycle approaches,” IEEE Trans. Software Eng., vol. 14, pp. 749-757, June 1988. [371 B. Boehm and F. Belz, “Applying process programming to the spiral model,” in Proc. 4th Inc. Software Process Workshop, ACM SIGSOFT (Moretonhampstead, Devon, UK), 1988, vol. 14, no. 4, pp. 46-56. [381 L. G. Williams, “Software process modeling: a behavioral approach,” in Proc. 10th Int. Conf on Software Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1988, pp. 174-186. [391 C. V. Ramamoorthy, V. Garg, and R. Aggarwal, “Environment modeling and activity management in Genesis,” in Proc. SOFTAIR-II, 1985, pp. 2-9. [401 L. Osterweil, “Automated support for the enactment of rigorously described software processes, ” in Proc. 4th Int. Software Process Work” \ 1 REFERENCES T. Teitelbaum and T. Reps, “The Cornell Program Synthesizer: A syntax directed programming environment,” Commun. ACM, vol. 24, no. 9, DO. 563-573. Scot. 1981. “?he GANDALF’ Project,” J. Syst. Sofrware, vol. 5, no. 2, May 1985. M. Dowson, Ed., “Iteration in the software process,” in Proc. 3rd Int. Software Process Workshop. Los Alamitos:.CA, IEEE Computer Sot. Press, 1986. [41 C. Tully, Ed., “Representing and enacting the software process,” in Proc. 4th Inc. Software Process Workshop, ACM SIGSOFT (Moretonhampstead, De&, UK), 1988, vol. 14, no. 4. [51 L. Osterweil, “Software processes are software too,” in Proc. 9th Int. Conf: on Sofiware Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1987, pp. 2-13. [61 M. M. Lehman, “Process models, process programs, programming support,” in Proc. 9th Inc. Conf on Software Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1987, pp. 14-16. [71 B. Curtis, H. Krasner, V. Shen, and N. Iscoe, “On building software process models under the lamppost,” in Proc. 9th Int. Co@ on Soware Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 1987, pp. 96- 103. PI G. Schiffner and H. P. Godbersen, “Function nets: a comfortable tool for simulating database system architectures,” Simulation, vol. 46, no. 5, pp. 201-210, May 1986. 191 L. Brownston, Programming Expert Systems in OPS5: An Introduction to Rule Based Programming. Reading, MA: Addison-Wesley, 1985. nianagement system for [lOI C. Lewerentz and A. Schuerr, “GRAS-a graph-like documents, ” in Proc. 3rd Inc. Conf: on Data and Knowledge Bases. Jerusalem: Morgan Kaufmann, 1988, pp. 19-31. Pll R.N. Taylor et al., “Next generation software environments: Principles, Problems. and Research Directions,” Univ. California, Irvine, Tech. Rep. No. 87-16, July 1987. [=I W. Deiters, V. Gruhn, and W. SchBfer, “Systematic development of formal software process models,” in Proc. European Software Eng. [II 1991 I, I , MADHAVJl [411 [421 1431 1441 [451 1461 [471 [481 AND SCHkFER: PRISM-METHODOLOGY AND PROCESS-ORIENTED shop, ACM SIGSOFT (Moretonhampstead, Devon, UK), 1988, vol. 14, no. 4, pp. 122-125. C. Roberts, “Describing and acting process models with PML,” in Proc. 4th Int. Software Process Workshop, ACM SIGSOFT (Moretonhampstead, Devon, UK), 1988, vol. 14, no. 4, pp. 136-141. V.R. Basili and H.D. Rombach, “The TAME project: towards improvement-oriented software environments,” IEEE Trans. Sofhvare Eni., vol. 14, pp. 759-773, June 1988. R. S. D’Inpoloito and C. P. Plinta, “Software development using mod.. els,” in Proc. 5th Int. Workshop on Software Spec.‘and Design, May 1989, pp. 140-142. N. H. Madhavji, “The Prism model of changes,” in Proc. 13th Int. ConJ on So&are Eng. Los Alamitos, CA: IEEE Computer Sot. Press, 199 1, pp. 166- 177. N. H. Madhavji, K. Toubache, and W. Hong, “Towards building reliable process models,” School Comput. Sci., McGill Univ., Montreal, PQ, Can., Tech. Rep. ProM-91.1, p. 28, Mar. 1991. N. H. Madhavji, “The Process cycle,” Software Eng. J. Special Issue on “Software Process and Its Support,” to be published. N. H. Madhavji, K. Toubache, and W. Hong, “Procuring quality process models through constraint-based specifications and iterations support,” School Comput. Sci., McGill Univ., Montreal, PQ, Can., Tech. Rep. ProM-91.4, Sept. 1991. N. H. Madhavji, K. Toubache, and W. Hong, “A framework for process evolution,” School Comput. Sci., McGill Univ., Montreal, PQ, Can., Tech. Rep. ProM-91.3, Sept. 1991. Nazim H. Madhavji obtained the Ph.D. degree in 1980 from the University of Manchester (UK). He joined McGill University, Montreal, PQ, Can., in 1983, where he is now a Professor and Acting Director of the School of Computer Science. His research interests are in software engineering, software processes, project management, software environments, and programming languages. He is heading ProM Canada, the Canadian component of a Canadian-German joint research project in software processes involving McGill, GMD (German National Research Center in Computer Science) and some industries. He is also head of the Software Process project in the Macroscope Initiative funded jointly by the Government of Quebec and some Quebec industries, and the IBM-McGill project on software process. He is a Program Co-Chair of CASE ‘92, to be held in Montreal. He has chaired sessions at international conferences on the subject of software environments. He is Guest Editor of the forthcoming IEE/BCS Software Engineering Journal special issue on software process. During the 1980-1982 period, along with Dr. I. R. Wilson, he built the first optimizing Pascal compiler for the CRAY-1 computer. ENVIRONMENT 1283 Wilhelm Schiifer obtained the Ph.D. degree in 1986 from the University of Osnabrueck. He then spent a year as a Visiting Faculty in the Computer Science Department at McGill University, Montreal. He is now a Professor in the Computer Science Department at the University of Dortmund, Germany. His main research interests are in software engineering, especially software process modeling, software reuse, design and evaluation of object management systems, and architectures of software development environments. Prior to of Dortmund, he was responsible for building up a research and development department of a software house in Dortmund, focusing on CASE tools and information systems. He is involved in a number of the European ESPRIT and EUREKA initiatives, either as a leading technical authority or as a reviewer. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.