Glossary


Plan-based Process

A-B-C-D-E-F-G-H-I-J-K-L-M-N-O-P-Q-R-S-T-U-V-W-X-Y-Z

Identification

Plan-based Process

Definitions/Uses

1998
Reference /Huff, 1988/ A Plan-based Intelligent Assistant that Supports the Software Development Process

Definition/
Use Extending environments to incorporate process support requires explicit representation of the software process, showing how software development goals are mapped into sequences of environment actions. (see figure below).
Typical goals (during implementation) are concerned with adding functionality to a system version, fixing bugs, adhering to various project-specific policies, and maintaining an organized on-line workspace. The actions available to achieve these goals consist of invocations of tools provided within the environment. Knowledge of a specific software process governs the mapping from goals to actions, distinguishing between the appropriate sequences of actions and random ones.
This view of software process fits the planning paradigm, an AI approach to a theory of actions. In planning, the knowledge of a domain is expressed in operators (parameterized templates defining the possible actions of the domain) together with a state schema (a set of predicates that describe the state of the world of that domain). Goals are logical expressions composed of the state predicates. A plan is a hierarchical, partial order of operators (with bound parameters) that achieves a goal given an initial state, and plan recognition, where a plan and ist goal are inferred given a sequence of actions and an initial state.
When the planning paradigm is applied to software processes, operators are the vehicle for formally defining processes; plans are the data structures that represents instantiations of processes; and, assistance can be active (via planning) or passive (via plan recognition).
Planning is distinguished from other theories of actions by its emphasis on goals to achieve, not actions to perform. Determination of actions proceeds from goals, so that contingency handling (e.g. for redundancy or failures) is internal - not external - to the planning system. When process definition is a procedural or event-based , the composition and ordering of actions is predetermined; any contingency handling must be built into the definition by hand, in advance. A behavioral approach to process modeling that combines action and goal orientation is described in /Williams, 1988a/.

1998
Reference	/Huff, 1988/ A Plan-based Intelligent Assistant that Supports the Software Development Process
Definition/ Use	Extending environments to incorporate process support requires explicit representation of the software process, showing how software development goals are mapped into sequences of environment actions. (see figure below). Typical goals (during implementation) are concerned with adding functionality to a system version, fixing bugs, adhering to various project-specific policies, and maintaining an organized on-line workspace. The actions available to achieve these goals consist of invocations of tools provided within the environment. Knowledge of a specific software process governs the mapping from goals to actions, distinguishing between the appropriate sequences of actions and random ones. This view of software process fits the planning paradigm, an AI approach to a theory of actions. In planning, the knowledge of a domain is expressed in operators (parameterized templates defining the possible actions of the domain) together with a state schema (a set of predicates that describe the state of the world of that domain). Goals are logical expressions composed of the state predicates. A plan is a hierarchical, partial order of operators (with bound parameters) that achieves a goal given an initial state, and plan recognition, where a plan and ist goal are inferred given a sequence of actions and an initial state. When the planning paradigm is applied to software processes, operators are the vehicle for formally defining processes; plans are the data structures that represents instantiations of processes; and, assistance can be active (via planning) or passive (via plan recognition). Planning is distinguished from other theories of actions by its emphasis on goals to achieve, not actions to perform. Determination of actions proceeds from goals, so that contingency handling (e.g. for redundancy or failures) is internal - not external - to the planning system. When process definition is a procedural or event-based , the composition and ordering of actions is predetermined; any contingency handling must be built into the definition by hand, in advance. A behavioral approach to process modeling that combines action and goal orientation is described in /Williams, 1988a/.

Related terms in the glossary

Process Operators
Process Plan

Publications on this area

Plan-based process

This page online • GDPA Online • Last Updated 16.June.2002 by C. Freericks