Structural Considerations in Defining Executable Process Models

This paper examines the question of how to structure the representation of a process in order to assure that the representation is effective in supporting such diverse activities as process understanding, communication among process participants, and process execution. The paper uses the example of a negotiation process to demonstrate that one process structure (which we refer to as the narrative form) seems to be quite effective in supporting understanding and communication, but then indicates that this structure seems problematic in supporting process execution. The paper indicates that a different structure (which we refer to as the role-oriented form) seems much more appropriate and effective in supporting execution, but may be lacking at supporting communication. In addition to serving different purposes, the two structures seem to represent different underlying models---a static process model, and a similar, but more complex, execution model. The properties of these two complementary structures are then analyzed and evaluated. The paper then uses these observations to raise questions about the underlying needs for effective process representation, suggesting in particular that a single process representation may not be a suitable basis for supporting the range of needs that process representations are expected to address.

[1]  Edward A. Lee,et al.  Scientific workflow management and the Kepler system , 2006, Concurr. Comput. Pract. Exp..

[2]  Leon J. Osterweil Software Processes Are Software Too, Revisited , 2011 .

[3]  George S. Avrunin,et al.  Using software engineering technology to improve the quality of medical processes , 2008, ICSE Companion '08.

[4]  Bashar Nuseibeh,et al.  Expressing the relationships between multiple views in requirements specification , 1993, ICSE '93.

[5]  Matthew Marzilli,et al.  A process-driven tool to support online dispute resolution , 2006, DG.O.

[6]  George S. Avrunin,et al.  Analyzing medical processes , 2008, 2008 ACM/IEEE 30th International Conference on Software Engineering.

[7]  Leon J. Osterweil,et al.  Software Processes Are Software Too, Revisited: An Invited Talk on the Most Influential Paper of ICSE 9 , 1997, Proceedings of the (19th) International Conference on Software Engineering.

[8]  Dietmar Pfahl,et al.  Software Process Dynamics and Agility, International Conference on Software Process, ICSP 2007, Minneapolis, MN, USA, May 19-20, 2007, Proceedings , 2007, ICSP.

[9]  Leon J. Osterweil,et al.  Early lessons from the application of process technology to online grievance mediation , 2005, DG.O.

[10]  Liming Zhu,et al.  Desiderata for Languages to be Used in the Defnition of Reference Business Processes , 2007, Int. J. Softw. Informatics.

[11]  Borislava I. Simidchieva,et al.  Representing Process Variation with a Process Family , 2007, ICSP.

[12]  Leon J. Osterweil,et al.  Unifying Microprocess and Macroprocess Research , 2005, ISPW.

[13]  Li,et al.  Unifying the Software Process Spectrum , 2006 .

[14]  Leon J. Osterweil,et al.  Software processes are software too , 1987, ISPW.

[15]  Lori A. Clarke,et al.  Experience in using a process language to define scientific workflow and generate dataset provenance , 2008, SIGSOFT '08/FSE-16.