We describe how an environment can be extended to support the process of software development. Our approach is based on the AI planning paradigm. Processes are formally defined hierarchically via plan operators, using multiple levels of abstraction. Plans are constructed dynamically from the operators; the sequences of actions in plans are tailored to the context of their use, and conflicts among actions are prevented. Monitoring of the development process, to detect and avert process errors, is accomplished by plan recognition ; this establishes a context in which programmer-selected goals can be automated via plan generation . We also show how nonmonotonic reasoning can be used to make an independent assessment of the credibility of complex process alternatives, and yet accede to the programmer's superior judgment. This extension to intelligent assistance provides deeper understanding of software processes.

No abstract

We describe how an environment can be extended to support the process of software development. Our approach is based on the AI planning paradigm. Processes are formally defined hierarchically via plan operators, using multiple levels of abstraction. Plans are constructed dynamically from the operators; the sequences of actions in plans are tailored to the context of their use. and conflicts among actions are prevented. Monitoring of the development process, to detect and avert process errors, is accomplished by plan recognition; this establishes a context in which programmer-selected goals can be automated via plan generation.We also show how nonmonotonic reasoning can be used to make an independent assessment of the credibility of complex process alternatives, and yet accede to the programmer's superior judgment. This extension to intelligent assistance provides deeper understanding of software processes. Goals are logical expressions composed of the state predicates. A plan is a hierarchical, partial order of operators (with bound

No abstract

IntroductionRecent progress in specifying and prescribing software development processes has demonstrated that automated support is an achievable goal. Automated support can, for example, prevent a programmer from starting compilations before an appropriate environment is set up, enforce a policy of regression and performance testing before a customer release, and insure that new source versions are checked back into the source code control system. Such support will be valuable to programmers, whose intellectual energies can be freed from many process details in order to be directed towards other pressing concerns; and, it will be. valuable to managers, who can be assured that certain project policies and conventions are routinely observed.The software development process tests a programmer's skilIs at both management of mundane details and creative, intelligent decision-making. Supporting the decision-making aspects of a process is a challenge, and all the more important because these decisions affect the most basic, common activities. If a process assistant lacks knowledge to address these decisions, it cannot independently critique a choice made by the programmer, nor can it present a restricted set of likely possibilities to the programmer for a final choice. This would be a serious limitation on the degree of support that can be achieved. In the remainder of this paper, we explore one approach to overcoming this limitation through deeper process modeling. Towards Deeper Process ModelsAs an example, consider how a programmer selects the baseline from which a new system version is to be developed. Usually, the baseline is the most recent system version; but, there are times when this is inappropriate. For example, the current customer release is the proper choice when repairing a bug for quick turnaround back to the customer; this choice avoids releasing new code that is not yet adequately tested. In order to provide support for baseline selection, there must be a decision procedure for distinguishing proper from improper baseline choices. While capturing the procedure with precision is difficult, acquiring the raw data needed as input is a seemingly insurmountable problem. Consider how this problem can be tackled.In reasoning about processes, programmers draw upon knowledge that governs and explains what bugs are, how they occur, why and how systems are built incrementally, and why and how systems consist of modular components. Some of this reasoning applies to facts directly observable from actions performed: what predecessor/successor relationship resulted from an editing action, which object modules were linked to make a particular load module, whether or not a particular system version was released to the customer, and the like. But, more importantly, much of the reasoning applies to facts that are not directly observable, and therefore not readily available to a process assistant. For example, reasoning about baseline choices involves (among other factors) a notion of purpose: is the new system version t...