review of the state-of-the-art (session summary)  the opening session of the 5th international software process workshop covered a wide range of topics so it is not possible to capture its full scope in this brief summary. this paper briefly outlines the main views expressed by the participants and then provides a precis of the participants' comments. because of the dynamic nature of those discussions, however, i have taken the liberty of grouping related points for a more coherent presentation. i also take full responsibility for any errors or omissions.  even though this first session was entitled "state-of-the-art," there was little discussion of actual process modeling experience. from the many examples given in the proceedings, however, there was considerable evidence of practical experience and the discussions reflected a general consensus that process modeling methods have been found both practical and helpful. while no examples were given of the unsuccessful application of formal methods, there was a strong minority view that such low-technology methods as procedure manuals and software standards were widely used and are often quite effective.  there was also general agreement that tools which include an implicit process were not true process models. to qualify as a process model, the process used by the tool should be explicitly defined. a strong consensus also held that the time had now come to more broadly apply these modeling methods to a range of well-known software process activities. it was felt this would provide useful insights on their development and introduction.  while there was no focused discussion on the objectives of process modeling, the purposes noted fell into three general categories:  to provide a precise framework for understanding, experimenting with, and reasoning about the process;  to facilitate process automation;  to provide a basis for process control.  an important role of process models is improvement of the combined human/technology activities involved in producing software. because of the dynamic nature of such people intensive work, it was suggested that these models should include the recursive capability to improve themselves.  a subject that was widely discussed and returned to again in subsequent workshop sessions was the special impact of the human element in software process models. while it was agreed that the human element adds considerable complexity, there were widely divergent viewpoints. these ranged from considering human-related issues as outside our area of competence to believing that such issues were central to all process work.  bill curtis opened this first session with a discussion of key issues and the following challenge: "how much of actual software development behavior will be affected (by process modeling) and what will be the benefit?" he then divided software process issues into two classes: the control process and the learning process. the former concerns management's need for an orderly framework for evaluating progress while the latter more closely approximates the exploratory and often intuitive nature of much software development work. sam redwine noted that software engineering could likely learn from the management methods used in developing and managing teams in professional sports.  the ensuing discussion was then focused by bill curtis' suggestion that configuration management would be a good place to initially apply process models since this well-understood function clearly distinguishes between product creations and the control of product evolution. peter feiler pointed out that configuration management should be viewed as having both support and control functions since it both helps the professionals do quality work and provides a controlled framework for system evolution. a number of other software development areas were then suggested for process modeling, including bug tracking, the product build process, and testing. anthony finkelstein noted that his process research focused on aspects of the requirements process because he feels this area has less support, is less well-defined, and that any results are thus more likely to have a substantial impact.  mark kellner raised the issue of the objectives of process modeling. with traditional software development, for example, software products are executed by machines while process programs must be understood and at least partially performed by people. this causes a fundamental paradigm shift. bill curtis suggested that an important role of process programs is to provide models for experimentation and learning. peter feiler also noted that process programs provide a precise basis for documenting, communicating, validating, simulating, controlling, and automating software development work. sam redwine further pointed out that an attachment to manny lehman's paper included a comprehensive listing of the potential roles of process models.  bill curtis then asked how the subject of process programming differed from traditional computer science. colin tully noted that with process programs, we are trying to describe processes that are not entirely executed by machine. in this effort, we have tended to accept the existing paradigms for software development. since these do not seem to fit too well, he questioned whether we are on the right track and if we know what paradigms are most appropriate.  gail kaiser and frank belz both felt that we would learn much from the paradigms of real-time systems design since both involve multiple asynchronous views of complex activities. peter feiler questioned whether process models differed that much from many other areas which involve people and tools in an overall process. a common problem is the search for promising areas to automate.  karen huff then made the observation that when dealing with people we can often focus on what we want done rather than the more explicit details of how it is to be accomplished. watts humphrey added that distinctions should be made between dealing with machines and people. with people, for example, the analog of the instruction set is neither clear, consistent across environments, or stable. there are also questions of motivation and accuracy and, as demonstrated by manufacturing experience, people do not perform very well when treated as machines. as demonstrated by the japanese in automobile production or by alcoa with aluminum sheet production, human performance is enhanced when they feel they own the process they are using. this is achieved in such cases by involving them in continuous process improvement. colin tully pointed out that this was manny lehman's issue with process programming.  dave garlan next asked why, in a state-of-the- art session, we were not hearing much about experience. was it that there were no real successes? lolo penedo pointed to the pml-pce work (described in the roberts and snowdon papers) as a good example. wilhelm schaefer noted they had considerable success in formally modeling the berlin headquarters of a large software operation. dieter rombach said that there is a growing body of modeling experience and that by devoting too much effort to selecting the right formalism we might repeat the futile programming search for the one right language. since there is not likely to be one best formalism, we should pick some real process examples and use available methods to model them.  bill curtis then raised the question of the qualifications for a process program. is make, for example, a process program? bob balzer contended that a tool with a built in, though not explicit, process was not a process program. dewayne perry agreed, although he felt that make partially qualified in that it coordinated the operation of other tools. frank belz then pointed out one of the dangers of building implied processes into tools. by selecting a single way to do a job which could be done in several different ways, the entire process is constrained to this single alternative. taly minsky noted an important distinction between tools and the larger processes which control them. with configuration management, for example, we are not dealing with one person systems. often the actions of a single individual can impact many others. this generally requires a consensus decision system. when one module is to be changed or promoted, the other involved modules must be, so to speak, consulted. when conflicts arise, these must be flagged and resolved before the proposed action can be taken. this requires sets of rules which raises the further question of what rules are appropriate and who writes them (see discussion of session #3 on policies). taly also suggested that there should likely be a rule-making hierarchy with different people having different rule- making authority.  bob balzer then suggested a separation of process modeling issues. one category concerned the activity domains which we can learn about and mechanize. as we see what is successful, we can make changes to provide further improvements. the other issue concerns the formal representation of the process, including its use of tools. mark dowson objected to the neatness of this paradigm. he interpreted bob balzer as saying that you first devise a model of the activity of interest, you than formalize its representation, and then finally mechanize it for execution. actual processes, he feels, do not work this way. we typically start with a vague idea of how to proceed, hack up a mechanization which works, and then improve it until it performs effectively. when we have worked with it long enough, we may finally understand the process and may in fact end up in much the same place. steve reiss suggested that in this work we should distinguish between those classes of models which can be mechanized and those that cannot. the latter, he feels, have to be dynamic because they generally deal with human behavior and management issues.  watts humphrey suggested that bob balzer include a third category: developing and improving the process. in fact, processes should generally have the recursive character of including the means for their own improvement. to achieve process ownership, effective human-intensive processes should then include these three activity classes. bob agreed that improvement was an essential process activity.  mark dowson suggested an important difference between reasoning about a process and process execution. he much prefers to learn from the process than from some product which contains an implied process. deciphering a process by studying a tool that embodies it is about as productive as attempting to understand a program from its object code. that is what convinced him of the importance of specification languages. karen huff also noted that a useful way to improve one's understanding of a process is to separate the enacting activities from those concerned with deciding what to do.  david notkin then raised an issue which largely occupied the concluding discussion of this session. he suggested that we might be using formalization and technology because that is what we like. he asserted that we can do a lot with low- technology processes. mark dowson agreed and noted that a lot of current process models used are based on manuals, procedures and standards. we cannot expect to find the one right formalization for everything; maybe different parts of the process should use different approaches.  watts humphrey noted that the current low-technology representations of process models often cause problems. for example, the standards and procedures manuals in many organizations are out of date and gather dust. while real processes are not static, their representations in tools and manuals tend to petrify. when we learn to use this technology appropriately it should help us to validate processes, to provide an appropriate and understandable level of abstraction, to support their execution, and to help keep them dynamic. if the process representation cannot conveniently be kept current, it will soon become obsolete and either unduly constrain behavior, be ignored, or be replaced.  marc kellner reinforced this view with his experiences in modeling several military processes for maintaining large software systems. in all cases they have such low-tech process descriptions as standards and procedures manuals but they are always out of date and unused. in no case that they have studied are the people actually following the official processes which are documented in the manuals. on close examination, in fact, they have found that these manuals are quite inaccurate and misleading.  clive roberts noted that low-technology process standards are much better than nothing. often, in fact, projects fail through not understanding their own process. dewayne perry added that, even when the programmers understand their process, they can also fail when they do not have the proper tools to understand their problems. mark dowson concluded that projects that get their process wrong are sure to fall on their face.  bob balzer returned to david notkin's point with the following three comments. we are now stuck with informal and out of date process definitions. if we do not explicitly represent our processes, we must leave them to the management system, and that has not worked very well for software so far. with formalization, we can get below the surface of our processes to better understand and improve them.  bill curtis concluded the session by noting that organizations work with processes of all levels of formality. the typical financial audit and control systems are quite formal. arthur anderson, for example, has an extensive training program for their new employees that teaches them exactly how to work with clients. while these guidelines may not be followed precisely in every case, they provide a working framework. in software, many organizations do not have any explicit representation of their process. it is like being lost; they feel out of control. often, in fact, they are.  watts humphrey