The PDF and Postscript versions of this paper contain this text, its formulas, and all figures.
In this paper we describe how explicit models of software or knowledge
engineering processes can be used to guide and control the distributed
development of complex systems. The paper focuses on techniques which automatically
infer dependencies between decisions from a process model and methods which
allow to integrate planning and execution steps.
Managing dependencies between decisions is a basis for improving the
traceability of development processes. Switching between planning and execution
of subprocesses is an inherent need in the development of complex systems.
The paper concludes with a description of the CoMo-Kit system which
implements the technologies mentioned above and which uses WWW technology
to coordinate development processes. An on-line demonstration of the system
can be found via the CoMo-Kit homepage: http://wwwagr.informatik.uni-kl.de/~comokit
In the future, the development of large software systems will be a typical task for virtual enterprises: People with different educational background (e.g. economics, computer science, arts for interface design) working on many locations all over the world (including emerging market countries like India or Eastern Europe) will have to work together to fulfill the business needs.
These features lead to certain requirements for process-supporting tools:
A (relatively) new direction in software engineering research (Armenise
et al. 92, Bröckers et al. 95, Huff 89, Verlage et al. 96) deals with
approaches to software process modeling. Their goal is to describe and
enact the way how software is produced and, in the long term, to improve
the software production process. In our CoMo-Kit project, on one side we
apply these approaches on the management and the coordination of large
knowledge engineering projects. On the other side, we improve them by using
AI techniques.
The next chapter gives an overview on the architecture of the CoMo-Kit
System which implements our concepts.
These resulted from an abstract view on the questions which must be
supported by a work process coordination tool:
The state of the implementation is described in chapter 6 and illustrated by a set of screenshots of a (small) knowledge engineering example. The last chapter gives a short summary and describes our current and future work.
The CoMo-Kit project of the University of Kaiserslautern focuses on
methods and techniques which support project planing and project coordination
for complex, distributed development and/or design projects. To evaluate
our approach we work on two application domains: software engineering,
which is the running example here and also in (Dellen, Maurer 96), and
urban land-use planning (Maurer, Pews 96, Maurer, Pews 95).
For a new development project, in a first step an initial project
plan is created. This plan contains descriptions of the tasks to
be done, a definition of the data structures which must be created during
task execution and a list of the team members involved in the design process.
Our approach allows to interlock planning and enactment. This is
a main feature for design processes because they only can be planned on
a detailed level when some steps have already been carried out. This is
one reason why normal workflow systems cannot be used for design tasks:
They require that the task flow is defined before the enactment
starts.
The current project plan is used by our Workflow Management Server,
the CoMo-Kit Scheduler, to support project enactment. Several clients are
implemented to work on subtasks of the process. E.g. we developed a CAD/GIS
client to work on the drawing tasks within the urban land-use planning
process.
Figure 1 shows the system architecture of CoMo-Kit. It consists of three main parts:
In the following we explain the concepts behind the Modeler and the Scheduler. A description of the Information Assistant is omitted because it is not within the scope of this paper on Project Coordination".
Project planning means developing a model how the project should be
carried out. For large-scale projects, a detailed plan can not be developed
before the execution starts but planning and execution steps must me interlocked:
Starting with an initial plan the first tasks are executed. Based on the
results, the plan is refined and/or extended. Now we will define the ingredients
of a project plan in our approach.
To model cooperative development processes, our Modeler uses four basic
notions: Tasks (Processes), Methods, Products (Concepts) and Resources.
In the following, these terms are defined as far as is necessary to understand
this paper omitting the syntactical details of our project planning language.
3.1 Tasks (Processes)
A task describes a goal to be reached while working on a project. Our
intended application domains deal with the production of information. Information
which is relevant for the project is described in the project plan. Therefore
we associate every task with a set of input and output parameters. In the
project plan, we are only able to state which type of information is used
or must be produced.
Example: The task requirements engineering" uses an object of type
informell problem description" as input and produces an object of
type requirements document" as output.
For every input the following flags mentioned in table 1are defined.
Table 1: Parameter Flags
| Flag Name | Meaning |
| needed for planning | The input must be available before the planning of the task starts |
| needed for execution | The input is not needed for planning but it must be available before the execution starts. |
| optional | The input neither needed for planning nor for execution (but it may be helpful to have). |
Outputs of a task may be optional or required.
Additionally, for every task a precondition and a postcondition may
be defined. Preconditions are, for example, used to check if the inputs
fulfill a given requirements. Postconditions are, for example, used to
check if the output of a task has a wanted quality.
Example: For a task implement program modules" the precondition
may be all module specifications completed" and the postcondition
may be module complexity < LIMIT".
When tasks are executed, decisions are made which result in assignments
of values to the output parameters. Our approach assumes that there
is a causal dependency between the available inputs and the produced outputs
of a task. We work on the principle that during project planning only
inputs are associated to a task which are relevant and necessary for reaching
the goal (Inadequacies of this assumption and their solutions are discussed
in Section 5.4).
3.2 Products (Concepts)
To model products which are created in the course of project execution,
an object-centered approach is used. As usual, we distinguish between classes
and instances. Classes define a set of slots to structure the product.
Every slot is associated with its type and cardinality. Types may be other
product classes or basic types (e.g. SYMBOL, STRING, REAL,...). During
process enactment we represent product instances as values which are assigned
to variables. The type of a variable is specified by a product class. Using
other product classes as the type of a slot creates complex object structures.
In the visualization of the product flows, these structures can be shown
on different levels of detail.
3.3 Methods
To solve a task, a method is applied. For every task, there may exist
a (predefined) set of alternative methods. Further, our approach allows
to define new methods when a task is planned or replanned.
Methods are executed by agents (see below).
We distinguish between atomic and complex (or composed) methods:
Atomic methods assign values (= instances of product classes) to parameters.
Process scripts describe how a given task is solved for humans. Process
programs are specified in a formal language so that computers can solve
a task automatically without human interaction.
Complex methods are described by a product flow graph. A product flow
graph consists of nodes which define parameters, (sub)tasks and links which
relate parameters to tasks. The direction of the link determines if the
parameter is the input or the output of the task. Every parameter is associated
with a product type: During process execution, the parameters may store
instances of this product type.
Subtasks can be further decomposed by methods. Along this line, the
decomposition of the overall task (e.g. develop software system")
can be seen as an AND-OR-Tree where tasks are AND-Nodes and methods are
OR-Nodes. The appropriate method for solving a task is selected during
process enactment.
3.4 Resources: Agents & Tools
Resources are used for project planning and task execution. Agents
are active entities which use (passive) tools for their work.
Tasks are handled by agents. We distinguish between actors (=
human agents) and machines .
For every task, the project plan defines the properties an agent must
have to work on it. Further, our system stores information about the properties
of every agent. For actors, we distinguish three kinds of properties: qualifications
(q), roles (r), and organization (o).
During task execution, our system compares the required properties of
a task with the properties an agent possesses. This allows to compute the
set of agents which is able to solve the task.
Example: In a project plan, it is defined that the task implement user
interface" should be executed by an actor which has skills in using
the Visualworks Interface Builder (q), is a programmer (r), and works in
department Dep 1.4 (o).
Having sketched our language for project planning, we now will explain
how the execution of plans is supported.
Conventional project management tools (e.g. MS Project) allow its users
to plan a project and manually check if it advances as planned.
The tool does not check if every planned task is executed nor does it provide
the information which is necessary for task execution.
Conventional workflow management systems (Georgakopoulos, Hornick 95,
Jablonski 95, Oberweis 94) require a complete model to be available before
the execution starts. Workflow management systems are only used for repetitive
processes because the effort to develop a model is high. So, it is not
feasible to use them for project planning.
Conventional groupware systems (e.g. Lotus Notes) basically are a means
for communication and allow its users to access relevant information. They
have no notion of a project plan and therefore are not able to support
the coordination of projects.
On contrary, our Scheduler
In the following, we will briefly illustrate the mode of operation of
the Scheduler and its architecture.
4.1 The CoMo-Kit Scheduler
For every project, a new Scheduler Instance is created and initialized
with a top level task. During task initialization, the task is delegated
to a set of agents. Then the Scheduler waits until an agent logs in and
accepts a task. After accepting a task, the agent chooses a method which
decomposes it into several finer-grained tasks. This is a planning step
and so the agent is only able to accept the task after all inputs which
are required for planning are available. Then the agents delegates every
subtask to a set of agents. If a task cannot be decomposed, the responsible
agent has to produce the outputs. The Scheduler guarantees that an agent
may only accept such a task if all needed inputs are available.
In Figure 2 the architecture of the CoMo-Kit Scheduler is shown.
The server component of the Scheduler is implemented with the object-oriented
database management system GemStone from Servio Corp. The server
The server component is accessible via a local area network from Visualworks
for Smalltalk-80 and C/C++-written clients. We developed clients in Visualworks
which allow to
For every task, a separate client can be used for planning. So, it is
possible to distribute the overall planning process to several agents.
Clearly, it is also possible to distribute the overall workflow (i.e. every
of its subtask) to several agents.
Using the Visualwave Package from ParcPlace Systems it is possible to
forward" the client interfaces via the world wide web (using Netscape,
Mosaic or other Web-Browser as the front end to the user). So, Visualwave
allows to distribute the work within a project via the Internet.
4.2 Developing & Executing Project Plans
Our framework allows to model arbitrary development processes. Anytime
the current plan can be extended by adding new methods or changed. So,
our approach supports incremental project planning.
From the point of view of a project manager, the planning and execution
cycle is as follows:
To summarize the approach: The Scheduler supports the coordination of
work processes by giving project managers means to plan a project and to
supervise how the plan is followed.
A problem which remains is how to support large teams in reacting on
changed decisions. In the following, we will show that if causal dependencies
between decisions are handled by a computer-based system, change processes
can be supported. The rest of this paper focuses on formalisms underlying
the dependency management. Our approach allows to acquire these causal
dependencies between decisions automatically from a project plan.
To manage causal dependencies between design decisions is necessary
to guarantee the traceability of the development process. If a system is
able to find out what is influenced by a decision, it is also able to inform
its users if the decision is changed.
The dependency management component is based on ideas from REDUX (Petrie
91, Petrie, Cutkosky 94). Extending Petrie's approach, our system deduces
dependencies automatically from a project plan. The postulated dependencies
have to be made explicit and managed with a suited mechanism (Maurer, Paulokat
94). By automatically deducing dependencies from the project plan, the
work load of users is reduced: They are not forced to enter all causal
relations between decisions manually.
From a project plan our system derives two kind of dependencies:
Now we will explain the formalisms which are used in our system to manage
dependencies.
To solve a task, a decision is made which results in variable
assignments or a decomposition of a task into subtasks (i. e.
the selection of a decomposition method). Rationales are arguments
for the validity of a decision or an information. Formally, a rationale
is a logical implication between predicates.
During project execution, former decisions may be found erroneous or
suboptimal. Then, they can be retracted and become invalid.
To formalize these notions, a set of predicates has been defined. At
every point in time, a predicate can be valid (TRUE) or invalid
(FALSE).
These rationales do not describe the discussion processes which lead
to a decision. They are only a means to handle dependencies between decisions.
Whenever a decision m is made, the related predicate decision(m)
is valid. If a decision must not be a part of the solution, the related
method is rejected . The rejection of a method mi is described
by a predicate rejected-decision(mi) and means that there is a hard
reason against this decision. The relation between the two predicates is
shown in Equation 1.
rejected-decision(mi) --> NOT decision(mi) (1)
For predicates, their rationales may be defined. Now we will explain
how these rationales can be extracted automatically from the project plan.
5.1 Dependencies within the Information Flow
During the enactment of tasks, information is used and produced. The
project plan specifies which information is used/produced and states the
type of the information. We assume that the information produced causally
depends on the information used. This implies that the output information
is in question whenever the inputs become invalid. An example illustrates
the underlying formalism.
Figure 3 shows the information flow for a task T . I, O1 and O2 are formal parameters (variables) of products. They define the type of a product and give a name to a product instance within the process model. T consumes a product of type PT1 referenced by variable I. It produces products named O1 and O2 .
Formally, the dependency between a decision and the assignment of values
to the output parameters is expressed with equation 2. The validity of
predicate assignment(O1=o1j) states that variable O1 is assigned
with value o1j .
decison(mj) --> assignment(O1=o1j) AND assignment(O2=o2j) AND ... AND assignment(Ov=ovj) (2)
If predicate decison(mj) becomes invalid, our system also invalidates
the assignments of the output variables.
Our goal was to make the validity of the outputs dependent on the inputs.
Formally, this is done by equation 3 together with equation 1.
NOT assignment(Ii=i1k) OR ... OR NOT assignment(In=ink) --> rejected-decision(mj) (3)
For every task, equations 1-3 are created by our system as soon as a
decision is made. Outputs of one tasks are inputs of others. During a design
process, long chains of dependencies are created. These decision chains
are the basis to guarantee traceability. The equations state a general
scheme for representing causal dependencies based on information flow.
5.2 Dependencies between a Task and its Subtasks
Coordinating large projects requires that every person involved knows
what to do and when to stop. If tasks are assigned to people and replanning
takes place, some tasks become invalid and the personal working on it has
to be informed about that fact. Our approach automates this and therefore
reduces the project coordination effort.
Complex methods decompose tasks into several smaller subtasks. If during
project enactment a decision for method mi is made, then subtasks
T1 ...Tv become valid and must be solved. Formally, this
dependency is expressed in equation 4. The predicate validSubtask(Ti)
is valid, as long as task Ti must be solved within the design process.
decision(mi) --> validSubtask(T1) AND validSubtask(T2) AND ... AND validSubtask(Tv) (4)
5.3 Dependencies based on the object structure
In CoMo-Kit, products are described in an object-centered manner. Therefore,
there are dependencies between assignments which result from the object
decomposition. E.g. if the assignment of a complex object to a variable
becomes invalid, also all its slots (which are filled by other assignments)
become invalid, too. These dependencies are implicitly contained in the
equations above: Products are incrementally created during tasks enactment
(by making a decision for a method). Every assignment of a value to a slot
is part of the decision chain which starts from the creation of the object
(no slots can be assigned if the object was not already created).
5.4 Limitations of the Automatic Deriveability of Causal Dependencies
The dependencies described above are automatically created based on
the project plan. In practical applications, one has to live with incomplete
project plans. This inadequacy may have several causes:
A standard plan (e.g. the design process may be described in a quality
management manual following ISO 9000ff) does often not match exactly to
the actual project or may be to coarse-grained.
Large projects often take a longer period of time. In the beginning,
these projects can only be roughly planned. For the first steps, perhaps
a detailed plan may be generated. Later steps can only be planned in detail,
when the results of the first are available (e.g. the implementation of
a software system can only be planned in detail when a specification is
available).
For the first point, one can argue that a "good" standard
plan will not show this inadequacy. But the second point is principle in
nature and can never be solved by pre-planning.
These problems result in the possibility that a causal dependency between
two information is not modeled in the project plan. It is also possible
that the model shows an input information which is not relevant for a task.
To overcome these two problems, our system allows its users to add new
or delete unnecessary design rationales during task enactment.
Additional Rationales: Formally, new rationales are entered by
changing equation 3. A decision may depend on:
The additional justifications change the condition for the rejection
as demonstrated in the following formulas (Italic characters in following
equations signal the additional justifications):
NOT assignment(Ii=i1k) OR ... OR NOT assignment(In=ink) OR NOT decision(mold1) OR ... OR NOT decision(moldM) --> rejected-decision(mnew) (5)
NOT assignment(Ii=i1k) OR ... OR NOT assignment(In=ink) OR NOT assignment(X1=xold1) OR ... OR NOT assignment(XM=xoldM) --> rejected-decision(mnew) (6)
NOT assignment(Ii=i1k) OR ... OR NOT assignment(In=ink) OR decision(mold1) OR ... OR decision(moldM) --> rejected-decision(mnew) (7)
NOT assignment(Ii=i1k) OR ... OR NOT assignment(In=ink) OR assignment(X1=xold1) OR ... OR assignment(XM=xoldM) --> rejected-decision(mnew) (8)
To clarify the formulas: If a decision depends on a condition then,
in our approach, its rejection depends on the negation of the condition.
Not necessary Rationales: Justifications of design decisions,
which are automatically derived from the model, describe dependencies contained
in the information flow. If some of those dependencies are irrelevant for
a particular decision in the current project, it is necessary to delete
them. As a result of this adaptation our system operates only on significant
justifications.
We achieve the adaptation of the logical description by removing the
related predicate (e.g. assignment(In=ink)) of a parameter assignment,
that does not influence the decision. This causes the following change
in Equation 3:
NOT assignment(Ii=i1k) OR ... OR NOT assignment(In-1=in-1k) --> rejected-decision(mnew) (9)
Surely, users are not forced to enter this formula directly but are
supported by a graphical user interface.
To handle the dependencies, a truth maintenance system is used (Doyle
79)
Now, we have explained the logical foundation of our work. Based on
the dependency management techniques, our system is able to automatically
inform involved users about changes.
In a local area network, this forward propagation is easily implemented
using the mechanisms of the GemStone-Smalltalk Interface. In the world
wide web, the forward pushing of information from the server to the client
is a bit unconventional. Alternatively, the users may manually update their
task agenda by accessing the server from time to time.
The CoMo-Kit Modeler is fully implemented as well as the CoMo-Kit Scheduler for the local area network. Currently, only plan execution is supported by a WWW-based version of CoMo-Kit which was developed using the Visualwave package.
In the following, we will illustrate the use of CoMo-Kit with a small
example. Figure 4 shows a decomposition of a knowledge engineering process.
For the top-level task KE_Project", two methods are defined: prototyping-oriented"
(in the actual model without any subtasks) and life-cycle oriented"
(which decomposes the top-level task into 8 subtasks System design"
- End user test"). One of is subtasks, namely Conceptual modeling",
can be solved by applying either method semi-formal specification"
or method formal specification". 
Figure 4: Task decomposition of a knowledge engineering process
Using the CoMo-Kit Modeler, one is able to describe the information flow of a method. Figure 5 shows the information flow of two methods. Basically, the method "life cycle oriented" tries to adapt the V-Model of software engineering processes to a knowledge engineering process. The method "semi-formal specification" refines the task "Conceptual modeling" into a set of subtasks. A closer look on the task "Conceptual modeling" in method "life-cycle oriented" shows that it gets the input "chunks" from the ancestor task "Protocol analysis" and produces a "conceptualModel" as output. Additionally, two concept instances are inputs to the task: "PSM library" allows to access a library of problem solving methods while working on the task. "Ontology library" allows to access the Ontology server in Stanford University (Farquhar et al. 96). In the method "semi formal Specification", these libraries are linked to two different tasks, namely "Select PSM" and "Select Ontology". Basically, by linking instances to a task, the user gets an easy access to relevant background information (or knowledge) which can be used in his work. Here, he is able to access libraries of ontologies and problem solving method and select those which can be reused in his current project.
Figure 5: Information flow of the methods "life-cycle oriented"
and "semi-formal specification"
The product model defines a set concepts (Figure 6). Figure 7 shows
a set of agents.
All these models can be edited and changed using the tools of the Modeler.
Further, they can also be changed during the execution of the process.
This increases the flexibility of the workflow engine, the Scheduler.
|
|
 |
| Figure 6: Product Model | Figure 7: Agent Model |
In the following, we will illustrate how the work processes is executed
using a standard World Wide Web Browser (Netscape). The first step is to
access the CoMo-Kit Desktop (Figure 8) which allows to create a new project
by selecting a process model (here: "KE_Process") and clicking
on the "New project" button. Then the user is able name the project,
to select a top-level task, and delegate it to a set of responsible persons
(Figure 9). As a result a new CoMo-Kit Scheduler is created and waits for
client requests.
Figure 8: The CoMo-Kit Desktop
Figure 9: Creating and initialising a new project
When a user decides to work for a project, he has to log in (Figure 10
a, b). As a result, he gets an agenda with tasks he may execute (Figure
10 c). 
Figure 10a: Selecting a Project to Log In
Figure 10b: Login
Figure 10c: Task Agenda
In Figure 11 the user has accepted the top-level task "KE_Process"
and has selected the method "life-cycle oriented". Currently,
he is delegating its subtasks to other agents.
Figure 11: Subtask Delegation
In the next figure, a user has accepted to work on task "select
ontology" and clicks now on the "ontology library" (Figure
12 a). Then he is connected to the Stanford ontology server (Figure 12
b).
Figure 12a: Working on an atomic method
Figure 12b: Ontology Server in Stanford
Using the CoMo-Kit desktop, a user is able to reject all decisions (Figure
13 a, b). The Scheduler then retracts all depending decisions resulting
in a consistent state. If, for example, the method "semi-formal specification"
is retracted, then all its subtasks are invalidated automatically and the
user can choose the alternative method "formal specification"
for this task. Additional, he may access a notification window which shows
him messages what has happened while he was not on-line (Figure 13 c).
As usual in software process modeling, the CoMo-Kit approach allows to describe arbitrary software development processes. Therefore, the approach can also be applied to support knowledge-based system development (which is illustrated in the example above). Additionally, our techniques allow to alternate planning and execution of design processes which is an advantage over other software process modeling approaches.
One main focus of our work is to handle dependencies between design decisions to improve project traceability and support humans in reacting on changes in a project. In our opinion, the techniques developed so far are necessary for supporting and coordinating (globally or locally) distributed workflows.
Based on our theoretical work, we implemented the CoMo-Kit Scheduler which allows to plan, coordinate and execute design processes. An implementation which allows to distribute the work in a local area network or the WWW is available now. The WWW-based version currently is restricted in its replanning functionality.
I want to thank Barbara Dellen and Gerd Pews for many stimulating discussions and the immense work they spent in developing, refining and improving CoMo-Kit. A lot of credits belong to our students Michael Albin, Michael Donner, Frank Leidermann, Nils Magnus, Thomas Rüger, Sascha Schmitt, and Max Wolf, who implemented most of the system.
P. Armenise, S. Bandinelli, C. Ghezzi, and A. Morzenti. Software process languages: Survey and assessment. In Proceedings of the Fourth Conference on Software Engineering and Knowledge Engineering, Capri, Italy, June 1992.
James W. Armitage and Marc I. Kellner. A conceptual schema for process definitions and models. In Dewayne E. Perry, editor, Proceedings of the Third International Conference on the Software Process, pages 153p;165. IEEE Computer Society Press, October 1994.
Sergio C. Bandinelli, Alfonso Fuggetta, and Carlo Ghezzi. Software process model evolution in the SPADE environment. IEEE Transactions on Software Engineering, 19(12):1128p;1144, December 1993.
Victor R. Basili: The Experience Factory and its Relationship to Other Improvement Paradigms, in: Ian Sommerville, Manfred Paul (eds.): Proc. of the 4th European Software Engineering Conference, P. 68-83, Lecture Notes in Computer Science Nr. 706, Springer Verlag, 1993.
Victor R. Basili and H. Dieter Rombach. The TAME Project: Towards improvementp;oriented software environments. IEEE Transactions on Software Engineering, SE-14(6):758p;773, June 1988.
Israel Z. Ben-Shaul, Gail E. Kaiser, and George T. Heineman. An architecture for multi-user software development environments. In H. Weber, editor, Proceedings of the Fifth ACM SIGSOFT/SIGPLAN Symposium on Software Development Environments, pages 149p;158, 1992. Appeared as ACM SIGSOFT Software Engineering Notes 17(5), December 1992.
Alfred Bröckers, Christopher M. Lott, H. Dieter Rombach, and Martin Verlage. MVPp;L language report version 2. Technical Report 265/95, Department of Computer Science, University of Kaisers-lautern, 67653 Kaiserslautern, Germany, 1995.
S. Buckingham Shum and N. Hammond. Argumentation-based design rationale: what use at what cost? Int. J. Human-Computer Studies, 40:603p;652, 1994.
J. Conklin and Begeman, gIBIS: A Tool for Exploratory policy Discussion, In Proceedings of CSCW '88 and ACM Transactions on Office Information Systems, October, 1988.
R. Conradi, Christer Fernström, and Alfonso Fuggetta. A conceptual framework for evolving software processes. ACM SIGSOFT Software Engineering Notes, 18(4):26p;35, October 1993.
B. Dellen, K. Kohler, F. Maurer: Integrating Software Process Models and Design Rationales, Proceedings Knowledge-based Software Engineering, IEEE Computer Society Press, 1996.
B. Dellen, F. Maurer: Integrating Planning and Execution in Software Development Processes, Proceedings of the Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE 96), IEEE Computer Society Press, 1996.
J. Doyle: A Truth Maintenance System, Artificial Intelligence, 12:231-272, 1979.
A. Farquhar, R. Fikes, J. Rice: The Ontolingua Sever: A tool for collaborative ontology construction, Proceedings KAW 96, 1996 (to appear)
P. H. Feiler and Watts S. Humphrey. Software process development and enactment: Concepts and definitions. In Proceedings of the Second International Conference on the Software Process, pages 28p;40. IEEE Computer Society Press, February 1993.
Ch. Fernström. Process WEAVER: Adding process support to UNIX. In Proceedings of the Second International Conference on the Software Process, pages 12p;26. IEEE Computer Society Press, February 1993.
P. K. Garg and Mehdi Jazayeri. Process-centered Software Engineering Environments. IEEE Computer Society Press, 1996.
D. Georgakopoulos. and M. Hornick: An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure, Distributed and Parallel Databases, 3, pages 119-153, Kluwer Academic Publishers, Boston 1995
K. Huff. Plan-Based Intelligent Assistance: An Approach to Support the Software Development Process. PhD thesis, University of Massachusetts, September 1989.
Institute of Electrical and Electronics Engineers. IEEE Standard for Developing Software Life Cycle Processes, 1992. IEEE Std. 1074-1991.
St. Jablonski: Workflow-Management-Systeme: Motivation, Modellierung, Architektur: From Informatik Spektrum 18: pages 13-24, Springer-Verlag 1995
M. Letizia Jaccheri and R. Conradi. Techniques for process model evolution in EPOS. IEEE Transactions on Software Engineering, 19(12):1145p;1156, December 1993.
J. Lonchamp: A structured conceptual and terminological framework for software process engineering. In Proceedings of the Second International Conference on the Software Process, pages 41p;53. IEEE Computer Society Press, February 1993.
A. Oberweis: Verteilte betriebliche Abläufe und komplexe Objektstrukturen: Integriertes Modellierungskonzept für Workflow-Managementsysteme, Habilitation Universität Karlsruhe, 1994
A. Mac-Lean et al.. Questions, Options and Criteria; Elements of Design Space Analysis. Human-Computer Interaction, 6: 201-250, 1991.
F. Maurer: Computer Support in Project Coordination, Proceedings of the Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE 96), IEEE Computer Society Press, 1996.
F. Maurer, G. Pews: Supporting Cooperative Work in Urban Land-Use Planning, Proc. COOP-96, 1996.
F. Maurer, J. Paulokat: Operationalizing Conceptual Models Based on a Model of Dependencies, in: A. Cohn (Ed.): ECAI 94. 11th European Conference on Artificial Intelligence, 1994, John Wiley & Sons, Ltd.
F. Maurer, G. Pews: Ein Knowledge-Engineering-Ansatz für kooperatives Design am Beispiel der Bebauungsplanung, Themenheft Knowledge Engineering, KI 1/95, interdata Verlag, 1995.
C. Petrie: Planning and Replanning with Reason Maintenance, Dissertation, University of Texas, Austin, 1991.
C. Petrie and M. Cutkosky. Design space navigation as a collaborative aid. In J. Gero and F. Sundweeks, editor, Artificial Intelligence in Design '94, Kluwer Academic Publishers, 1994
C. Potts and G. Bruns, Recording the Reasons for Design Decisions, In Proceedings of the 10th International Conference on Software Engineering, pages 418-427, 1988.
Special Issue on Design Rationale, Human-Computer Interaction, 6: 197-419, 1991.
M. Verlage, B. Dellen, F. Maurer, and J. Münch. A synthesis of
two process support aproaches. In Proceedings of the 8th Software Engineering
and Knowledge Engineering Conference (SEKE'96). Knowledge Engineering Institute,
June 1996.
