Process modeling

From Wikipedia, the free encyclopedia

The term process model (usually business process model) is used in different contexts. Process models are concepts which can belong in the area of Process Engineering.

A description of what process models are is provided by Colette Rolland: “Processes of the same nature are classified together into a process model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. […] One possible use of a process model is to prescribe ‘how things must/should/could be done’ in contrast to the process itself which is really what happens. A process model is more or less a rough anticipation of what the process will look like. What the process shall be will be determined during actual system development” [Rolland1998]

Contents 1 Main aims 2 Purpose 3 Classification of process models 3.1 Classification by coverage 3.2 Classification by alignment 3.3 Classification by granularity 3.4 Classification by flexibility 4 Techniques 5 See also 6 References

[edit] Main aims

• descriptive
  • traces what actually happens during a process
  • takes the point of view of an external observer who looks at the way a process has been performed and determines the improvements that have to be made to make it perform more effectively or efficiently
• prescriptive
  • defines desired processes and how they should/could/might be performed
  • lays down rules, guidelines, and behavior patterns which, if followed, would lead to the desired process performance. They range from strict enforcement to flexible guidance.
• explanatory
  • provides explanations about the rationale of processes
  • explores and evaluates several possible courses of action based on rational arguments
  • establishes an explicit link between processes and the requirements that they are to fulfill

[edit] Purpose

“From a theoretical point of view, the Process Meta-Model explains which are the key concepts needed to describe what happens in the development process, on what, when it happens and why. From an operational point of view, the Process Meta-Model is aimed at providing guidance for method engineers and application developers.” [Rolland1993],

The activity of modeling a business process usually predicates a need to change processes or identify issues to be corrected. This transformation may or may not require IT involvement, although that is common driver for the need to model a business process. Change management programmes are desired to put the processes into practice. With advances in technology from larger platform vendors, the vision of BPM models becoming fully executable (and capable of round-trip engineering) is coming closer to reality every day. Supporting technologies include River Logic Inc., Unified Modeling Language (UML), model-driven architecture, and service-oriented architecture.

Process Modeling addresses the process aspects an Enterprise Business Architecture, leading to an all encompassing Enterprise Architecture. The relationships of a business processes in the context of the rest of the enterprise systems, data, org structure, strategies etc. create greater capabilities in analyzing and planning a change. One real world example is in corporate mergers and acquisitions; understanding the processes in both companies in detail, allowing management to identify redundancies resulting in a smoother merger.

PM has always been a key aspect of business process reengineering, and continuous improvement approaches seen in Six sigma.

[edit] Classification of process models

[edit] Classification by coverage

[Dowson1988] distinguishes four types of coverage where the term process model has been defined differently:

• Activity-oriented: related set of activities conducted for the specific purpose of product definition; a set of partially ordered steps intended to reach a goal [Feiler1993]
• Product-oriented: series of activities that cause successive product transformations to reach the desired product
• Decision-oriented: set of related decisions conducted for the specific purpose of product definition
• Context-oriented: sequence of contexts causing successive product transformations under the influence of a decision taken in a context

[edit] Classification by alignment

With regard to Rolland [Rolland1998], processes can be of different kinds. These definitions “correspond to the various ways in which a process can be modelled”.

• Strategic processes
  • investigate alternative ways of doing a thing and eventually produce a plan for doing it
  • are often creative and require human co-operation; thus, alternative generation and selection from an alternative are very critical activities
• Tactical processes
  • help in the achievement of a plan
  • are more concerned with the tactics to be adopted for actual plan achievement than with the development of a plan of achievement
• Implementation processes
  • are the lowest level processes
  • are directly concerned with the details of the what and how of plan implementation

[edit] Classification by granularity

Granularity refers to the detail level of the process model. “Granularity affects the kind of guidance, explanation and trace that can be provided. High granularity limits these to a rather coarse level of detail whereas fine granularity provides more detailed capability. The nature of granularity needed is dependent on the situation at hand.” [Rolland1998]

Project manager, customer representatives, the general, top-level, or middle management require rather large-grained process description as they want to gain an overview over time, budget, and resource planning for their decisions. In contrast, software engineers, users, testers, analysts, or software system architects will prefer a fine-grained process model for the details of the model deliver them with instructions and important execution dependencies such as the dependencies between people.

While notations for fine-grained models exist, most traditional process models are large-grained descriptions. Process models should, ideally, provide a wide range of granularity. (e.g. Process Weaver [Fernström1991]) [Rolland1998]

[edit] Classification by flexibility

It was found that “even though process models were prescriptive, in actual practice departures from the prescription occurred”. [Rolland1999] Thus, frameworks for adopting methods evolved so that systems development methods match specific organizational situations and thereby improve their usefulness. The development of such frameworks is also called Situational Method Engineering.

Method construction approaches can be organized in a spectrum ranging from 'low' flexibility, to 'high'. [Harmsen1994]

“At the 'low' end of this spectrum are rigid methods whereas at the 'high' end is modular method construction. Rigid methods are completely pre-defined and leave little scope for adapting them to the situation at hand. On the other hand, modular methods can be modified and augmented to fit a given situation. Selection from rigid methods allows each project to choose its method from a panel of rigid, pre-defined methods whereas selection of paths within a method consists of selecting the appropriate path for the situation at hand. Finally selection and tuning a method permits each project to select methods from different approaches and tune them to the project's needs.” [Rolland1997]

[edit] Techniques

Rolland [Rolland1998] lists different styles for representing processes: scripts, programs, and hypertext. “Process scripts are interactively used by humans as against process programs which are enacted by a machine. They support non determinism whereas process programs can, at best, support process deviation under pre-defined constraints. The hypertext style of process representation is a network of links between the different aspects of a process, such as product parts, decisions, arguments, issues, etc. […] Scripts and programs are two styles which may be applicable to prescriptive purposes whereas hypertext is well suited to descriptive and explanatory purposes. Strict enforcement of the prescriptive purpose can clearly be represented in process programs whereas flexible guidance requires the process model to be represented in process scripts. Descriptive and explanatory purposes require the establishment of relationships between different elements of a process trace. These relationships are well articulated as hypertext links.”

	Process Representation style
Perspective	Scripts	Programs	Hypertext
Usage	interactively used by humans	enacted by a machine	network of links between the different aspects of a process, such as product parts, decisions, arguments, issues, etc.
Character	support non determinism	support, at best, process deviation under pre-defined constraints
Applicability	applicable to prescriptive purposes (flexible guidance)	applicable to prescriptive purposes (strict enforcement)	applicable to descriptive and explanatory purposes

Rolland [Rolland1998] states that, traditionally, informal notations such as natural languages or diagrams with informal semantics have been used as process models underlying information systems. She continues saying that, in software engineering, more formal process models have been used. [Armenise1993], [Curtis1992], and [Finkelstein1994] give an overview of them. This formality relates to underlying programming languages : Smalltalk for E3 [Finkelstein1994], various Prolog dialects for EPOS [Jacherri1992], Oikos [Ambriola1991], and PEACE [Finkelstein1994], PS-Algol for PWI [Finkelstein1994].

[edit] See also

• Business Process Management
• BPMN
• Domain Specific Language
• Model Driven Engineering
• Process architecture

[edit] References

[Ambriola1991]	V; Ambriola, M. L. Jaccheri, Definition and Enactment of Oikos software entities, Proc. of the First European Workshop on Software Process Modeling, Milan, Italy, 1991
[Armenise1993]	P. Armenise, S. Bandinelli, C. Ghezzi, A. Morzenti, A survey and assessment of software process representation formalisms Int. Journal of Software Engineering and Knowledge Engineering, Vol. 3, No. 3, 1993.
[Curtis1992]	B. Curtis, M. Kellner, J. Over, Process Modeling, Communications of ACM, vol 35 n°9, september 1992, pp 75-90.
[Dowson1988]	M. Dowson. Iteration in the Software Process, Proc 9th Int. Conf. on Software Engineering, 1988.
[Feiler1993]	P. H. Feiler, W. S. Humphrey. Software Process Development and Enactment: Concepts and Definitions, Proc. 2nd Int. Conf. on "Software Process", 1993.
[Fernström1991]	C. Fernström, L. Ohlsson, Integration Needs in Process Enacted Environments, Proc. 1st Int. Conf. on the Software Process, IEEE computer Society Press, October 1991.
[Finkelstein1994]	A. Finkelstein, J. Kramer, B. Nuseibeh (eds). Software process modelling and technology. Wiley, New York, 1994
[Harmsen1994]	A. F. Harmsen, J. N. Brinkkemper, J. L. H. Oei; Situational Method Engineering for information Systems Project Approaches, Int. IFIP WG8. 1 Conf. in CRIS series: Methods and associated Tools for the Information Systems Life Cycle (A-55), North Holland (Pub. ), 1994.
[Jacherri1992]	L. Jacherri, J. O. Larseon, R. Conradi, Sotware Process Modelling and Evolution in EPOS, in Proc. of the 4th Int. Conf. on Software Engineering and Knowledge Engineering (SEKE'92), Capri, Italy, 1992, pp574-589.
[Rolland1993]	C. Rolland. Modeling the Requirements Engineering Process, 3rd European-Japanese Seminar on Information Modelling and Knowledge Bases, Budapest, Hungary, June 1993.
[Rolland1997]	C. Rolland. A Primer for Method Engineering. Proceedings of the INFORSID Conference (INFormatique des ORganisations et Systemes d'Information et de Decision), Toulouse, France, June 10-13, 1997.
[Rolland1998]	C. Rolland. A Comprehensive View of Process Engineering. Proceedings of the 10th International Conference CAiSE'98, B. Lecture Notes in Computer Science 1413, Pernici, C. Thanos (Eds), Springer. Pisa, Italy, June 1998
[Rolland1999]	C. Rolland, N. Prakash, A. Benjamen. A Multi-Model View of Process Modelling. Requirements Engineering. Volume 4, Number 4. Springer-Verlag London Ltd , 1999