 |
 |
|
 |
 |
|
|
|
|
|
|
Encyclopedia :
P :
PR :
PRO :
Process Modeling |
|
|
Process ModelingDefinitionThe term process model is used in different kind of contexts; most prominently business process models. The context in which process models will be described in the forthcoming sections, will be Information System Development. There, process models are concepts which belong to the wider area of Method Engineering, more specific Process Engineering. [[Image:meta-levels.png|frame|right|100px|Abstraction level for processes [Rolland1993] 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] 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], Classification of process modelsClassification by coverage[Dowson1988] distinguishes four types of coverage where the term process model has been defined differently:
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] Classification by flexibilityIt 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] [[Image:flexibility.png|frame|right|100px|Flexibility of Method construction approaches [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] TechniquesRolland [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.”
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]. References
|
||||||||||||||||||||||||||||||||||||||||||||||
|
|
This article is from Wikipedia. All text is available under the terms of the GNU Free Documentation License. |
|
| © 2008 Chamas Enterprises Inc. |
