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.