Summary of Software Process Models

1 Process Modeling [2]

This paper overviews the process modeling work in some aspects and provides a definitive assessment of the research issues. A conceptual framework of process modeling is described before the further discussions. Basic concepts like process, process element, process step, agent, role, artifact and process script/program are defined in this framework.

Four perspectives in process representation which are functional, behavioural, organizational, and informational, are proposed to analyze and present process information. The author assumes that when combined, these perspectives will produce an integrated, consistent, and complete model of the process analyzed. Therefore, these perspectives are used to analyze many process modeling languages. However, no language can support all these perspectives.

In order to summarise the breadth of process modeling research, five approaches to representing process information which are programming model, functional model, plan-based model, Petri net model, and quantitative model are described, each with an example.

Three important issues in process modeling are described: formality, granularity and precision, and scriptiveness and fitness. These issues should be considered depending on the purpose served by the process model and attributes of the agents that must execute the process.

At last, several aspects of future directions are analyzed. How to support all perspectives described above by multi-paradigm representations is discussed. How to improve process and manage software project by process modeling is argued. Moreover, issues about process-based software development environments are described.

My Thoughts:

This paper is an excellent overview for software process modeling. The use of the perspectives gives us more insights about the process information. The five approaches to represent the process information make a good view to the process modeling languages.

2 Software Processes are Software Too [7]

An idea that software processes and software products have much in common, thus we should use a process program to describe a software process is proposed in this paper. Moveover, the author believes that the activity that expresses software process descriptions with programming techniques ought to be at the center of what software engineering is all about.

The process programming which is a rigorous description of software processes provides a vehicle for the materialization of the processes by which we develop and evolve software. Different people can communicate easily through software programs. Software processing also supports the reuse of software processes because it records the details of the processes precisely. Additionally, sufficiently elaborated process program can be analysed and interpreted automatically by a computer. Moveover, it is expected that the processes which we employ to develop and evolve end-user software products should also be applicable to the development and the evolution of process program descriptions.

Some future directions of process programming are also discussed in this paper .

My Thoughts:

Process evolution is an important issue in software process programming. However, process programming does not support it directly. I think a meta-process which describes how to interpret the process programs can support the process evolution well. This meta-process should support dynamic binding of the data and suspending/resuming of the processes.

A process program is not a pure program, that is, it cannot be executed only by a computer. Many tasks must be executed by an external tool, like human or another program. Therefore, the process program should support external tools.

An important point of process programming is that it can facilitate the communication among people. However, for a large process model, the process program is difficult to understand. This is because the language a process program used is designed for computers, not for humans. Moveover, processes are often parallel, which makes the design and understanding of process programs much harder. This also impedes the reuse of the process programs. Therefore, process programming may be less useful when describing large process models.

3 Process Models, Process Programs, Programming Support [4]

This paper is a response to the paper Software Processes are Software Too [7]. The author cautions against using the programming notions for process modeling and believes that the process programs have limited values in the context of improvement of the software development and evolution process.

Process programming is only useful when developing process programs for describing the well-understood processes. If we do not know the processes well and do not know the strategies and algorithms for achieving the desired ends, process programming is meaningless.

Moerover, when trying to solve a problem by describing the process for it, the process programming can severely limit human creativity. Language is a screen standing between the thinker and reality. A programming language which has much weaker verbal and expressing power than the natural language can make the thinker much harder to solve the problem.

My Thoughts:

The author thinks that the process programs can only be used to describe well-understood processes. However, I think process programming can not do well even in this area. Converting a description of the process to a process programming is not easy, just like to develop a software. And the main meaning of this effort lies in facilitating the communication among people. But understanding a complex program is much harder than understanding the normal description of the processes for human.

4 Software Process Development and Enactment: Concepts and Definitions [3]

This paper defines a core set of concepts about the software processes. These concepts are intended to facilitate communication and to provide a framework for further definitions. These precisely defined concepts and definitions can also enhance one's ability to think about the software process models.

The definitions in this paper are developed within the context of the authors' views and opinions on the software process. A definition framework is defined which identifies the overall relationships among software and process activities and indicates the activities to which the various definitions relate. Based on this framework, essential process concepts, which cannot easily be derived from other concepts are defined.

The definitions are grouped into four sets: a Framework for Process Definition, an Engineering of Process, an Enactment of Process, and Process Properties. The Framework for Process Definition defines foundation terms that are used in the subsequent definitions. The terms in Engineering of Process elaborate on the process of developing process definitions. Concepts concerning the enactment and management of the defined processes are described in Enactment of Processes. Finally, terms defining properties of the defined processes are discussed in Process Properties.

My Thoughts:

All concepts and definitions in this paper are based on the authors' framework of software process. If this framework is not appropriate for the software process, or too special to conclude the software process field, the meaningness of the concepts and the definitions is doubted. Therefore, the generality of the framework is very important.

This paper pays attention to the evolution of software process. For example, Evolution which is defined in the Engineering of Process and Process Control which is defined in the Enactment of Processes can be used to describe the evolution of software processes. However, the support for the evolution is not enough. The process evolution during the enactment of the process needs concepts like Suspend and Resume which are not included in this paper.

5 The Process Cycle [6]

This paper gives an overview of the role of processes in the software engineering and the software environments. It unfolds many hidden lower level process details so as to present an improved understanding of the development of the processes. Four key levels of abstraction in a process-oriented software environment which are software products, software product engineering and evolution facilities, software process, and software process engineering and evolution facilities are identified. These levels are aimed at supporting the evolution of software products as well as software processes.

It introduces the concept of process cycle, which is a concise and integrated view of engineering, managing, performing and improving the software processes. The process cycle includes three sectors: engineering process models, managing software process, and performing software processes. It defines the scope of the total set of process steps necessary for the development and the evolution of software processes. In addition, the process cycle defines the key roles played by human beings, the categories of tools used, the goals and policies governing the processes, and the inter-relationships and feedback among the different roles.

My Thoughts:

The process cycle proposed in this paper is a good view of the software process engineering and management. It includes many important issues of the software process models. However, it is too concise to include some useful details, e.g., in the process performing sector of the process cycle, process control, process authority and process assurance are not shown.

6 Software Process Model Evolution in the SPADE Environment [1]

This paper introduces a language SLANG that can model, enactment and support the evolution of software processes.

The SLANG consists of the sets of Process Types and the sets of Process Activities. All data that are produced, used, and manipulated in a software process are types of the Process Types. Type definitions are organized in a hierarchy, defined by an is\_a (or subtype) relationship. Process Activities is a set of activity definitions. Each activity definition is an instance of the type Activity and is specified as a high-level Petri net. Events are represented by transitions in the Petri net. The black transition is used to invoke the external tools which are non-SLANG executable routines. The SLANG uses the black transition to interact with external tools and humans in a uniform manner. Normal transitions of the SLANG contain guards and actions which define the preconditions and actions of themselves.

The SLANG is used to define both process models and meta-process models. The meta-process model is used to define how to execute a process model. A meta-process which can read the definitions of process types dynamically and suspend/resume a process is defined in this paper. When a process is suspended, both the process model and the process state can be modified when needed. This meta-process can be used to support the evolution of processes. After the process model changes, the new execution of the process will read the new definitions of the process. Even the executing process can be suspended and resumed with the new process model or new states.

My Thoughts:

I believe that the power of the formal language SLANG is the supporting of process evolution. The SLANG is based on the Petri net, but is much powerful than Petri net. For each transition, there is a guard and action. This supports complex conditions and actions to fire a transition. The support of aggregation lets the SLANG express complex process models easily.

Although the SLANG supports the evolution of a process during its execution, this should be done very carefully to avoid the possible conflicts caused by the evolution. For example, if a process is suspended at a state, and then this state is removed as a result of the evolution, what will SLANG do to resume the execution of this process? A mechanism to process unexpected events like exception-processing may be very useful to deal with these conflicts.

7 A Formal Model for Software Project Management [5]

A formal model called DesignNet for describing and monitoring the software development process is presented in this paper. The DesignNet supports iterative processes such as project replanning and project history. Moreover, it can efficiently support the computation of some useful properties of a project, e.g., connectedness, plan completeness, and plan consistence. It is a hybrid model which utilizes the AND/OR graph and the Petri net.

The AND/OR graph is used to describe the work breakdown structure. The products and the activities are organized in aggregations by the AND or the OR operators in the DesignNet. Therefore, the aggregation information of a higher level node can be collected from its constituents.

The Petri net is used in the DesignNet to describe the dependencies among activities, resources and products. The typed places can describe activities, products, resources, and status report information of the project. The transitions can represent the prerequisites and the end of the activities. To record the execution history of a project, the tokens of the DesignNet are not volatile. The DesignNet stores all tokens in their corresponding places. Much relative information can also be stored within the tokens.

My Thoughts:

It is a good idea to combine the concepts of the AND/OR graph and the Petri Net. The DesignNet uses the AND/OR graph to represent the static structure of the project. The Petri net is used in the DesignNet to represent the dynamic execution of the project. The use of the concepts of the Petri net is the key for the DesignNet to support iterative processes.

There are some differences between the DesignNet and the Petri Net which can be seen in the following table.

There is no time information in the DesignNet, thus we can not know the time needed for each activity. However, the time information is very important for managing a project. The time needed to finish an activity should be added as an attribute of the activity. In order to represent complex projects, the hierarchical modeling should also be used in the DesignNet.

8 PROCESS WEAVER [8]

PROCESS WEAVER is a workflow environment which can be used to manage the process of individual tasks or a sequence of tasks performed by a team. It offers a comprehensive combination of the functions for modeling, enacting, and monitoring business processes. Its client/server architecture and application integration ability make PROCESS WEAVER support distributed, heterogeneous environments well.

PROCESS WEAVER provides tools for four different process management roles: the organizer, the participant, the owner and the system administrator.

Process participants are responsible for carrying out the tasks defined by a business process. The Agenda is a control panel for each participant. Different tasks are organized in the Agenda. The participants can start Work-contexts from the Agend so as to accomplish the task.

Process organizers are responsible for designing process models which represent the business practices to be enacted in their organizations. The Method Editor is used to define hierarchical activities. The Activity Editor is used to define properties of the activities. The Work-context Editor is used to define the Work-context used by the participants. The Cooperative Procedure Editor is used to define the sequencing and the interaction of the activities - the process model. PROCESS WEAVER uses a model similar to Petri Net to represent the processes. Places are used to represent states, and transitions are used to represent activities. A transition contains a condition and an action. PROCESS WEAVER has many standard conditions and actions. The organizers can also define their own conditions and actions by the language CoShell which is a powerful and flexible language provided by PROCESS WEAVER.

Process owners are responsible for monitoring the execution of a business process. They can use the Tracer and the control panel to monitor useful operations and events during the execution of a process. They can also use the Viewer to view the current execution status of the process.

The system's administrator manages the environment of PROCESS WEAVER and integrates PROCESS WEAVER with other applications.

My Thoughts:

The use of conditions and actions makes the model of PROCESS WEAVER more powerful than the Petri Net. The CoShell language permits PROCESS WEAVER to describe complex process models.

In the process models of PROCESS WEAVER, there is no time constraints. Therefore, the owners can not know the time needed to accomplish a task which is important when managing large tasks.

The evolution of a process model during its enactment is important. PROCESS WEAVER can support some evolutions, but not complete. The owner of a running process can change the status or values of this process. However, this paper does not describe how to change the executing process models .

Process modeling has a much wider scope than software development. Any projects which include partly ordered set of activities, resources and products can be described by process models. The parcularity of the software development is that the products produced by a software process are intangible and invisible [7].

Petri Net

Petri net is often used in process modeling. An exmple is the DesignNet [5], which combines the AND/OR graph and the Petri Net. It can describe the iterative processes and compute useful properties of a process model. The SLANG language of SPADE environment [1] is also built over a high-level Petri Net. It provides the meta-process to support the evolution of the processes. PROCESS WEAVER [8] is a workflow environment to manage business processes. The Cooperative Procedure Editor in it is also based on a Petri net.

The reason that many modeling languages select Petri net is that all processes are asynchronous concurrent activities which can be described by Petri net very well. However, the simpleness of Petri net can not satisfy the requirements of process modeling. Therefore, these models extend the Petri net in a similar way: using typed tokens (DesignNet, SLANG), using typed places (DesignNet), and applying conditions and actions to the transitions (SLANG, PROCESS WEAVER).

Process Evolution

Once a process model is designed, it will face the evolution. During the execution of a process, there are two reasons for process evolution:

• Unknown Event. At the time the process is described, the project does not begin, so many details are unavailable. Moreover, some details can only be fully undertood as late as the execution of the process. Therefore, the evolution of process happens.
• Unexpected Event. When an unexpected event occurs and the process cannot deal with it, the process must be changed. Because of the complexity of the process, unexpected events can not be avoided totally.

From the above analysis, we know that the process evolution is not avoidable in the execution of a process. A successful process model should support process evolution efficiently. Some process models support the time constraints which can be used to estimate the accomplish time of a project. However, because of the process evolution, this estimation cannot be very accurate. Therefore, enlarging the time with some extent to get a good estimation of finishing time is a clever way. In Microsoft, Program Managers always spare some time to cope with unknown and unexpected events. Although they do not know what events will occur, they know that some events will do occur [9].

[1] Sergio C. Bandinelli, Alfonso Fuggetta, Carlo Ghezzi. Software Process Model Evolution in the SPADE Environment.
IEEE Transaction on Software Engineering, Vol. 19, No. 12, December 1993, pp. 1128-1144

[2] Bill Curtis, Marc I. Kellner, Jim Over. Process Modeling.
Communications of the ACM, September 1992, Vol 35, No. 9

[3] Peter H. Feiler, Watts S. Humphrey. Software Process Development and Enactment: Concepts and Definitions.
Proc. 2nd Int'l Conf. Software Process, IEEE CS Press, Los Alamitos, Calif., 1993, pp. 28-40

[4] M.M. Lehman. Process Models, Process Programs, Programming Support. Response To An ICSE9 Keynote Address By Lee Osterweil
Proc. 9th Int'l Conf. Software Eng., ACM Press, New York, N.Y., 1987, pp. 14-16

[5] LungChun Liu, Ellis Horowitz. A Formal Model for Software Project Management.
IEEE Transactions on Software Engineering, Vol. 15, No. 10, October 1989

[6] Nazim H. Madhavji. The Process Cycle.
Software Engineering, September 1991, pp. 234-242

[7] Leon Osterweil. Software Processes Are Software Too.
Proc. 9th Int'l Conf. Software Eng., ACM Press, New York, N.Y., 1987, pp. 2-13

[8] PROCESS WEAVER, General Information Manual

[9] Richard W. Selby, Michael A. Cusumano, Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People, Microsoft Press, 1995