Content deleted Content added
Red Phoenix (talk | contribs) m Reverted edits by 41.66.209.130 (talk) (HG) (3.4.9) |
Link suggestions feature: 3 links added. |
||
| (10 intermediate revisions by 8 users not shown) | |||
Line 1:
{{Short description|Definition and description of a process or system}}
{{for|the jargon used in the Australian republican debate|Process model (Australia)}}
The term '''process model''' is used in various contexts. For example, in [[business process modeling]] the enterprise process model is often referred to as the ''business process model''.
Line 24 ⟶ 25:
From a theoretical point of view, the [[meta-process modeling]] explains 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 meta-process modeling is aimed at providing guidance for method engineers and application developers.<ref name=Rolland1993/>
The activity of [[business model|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 a 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 business process models (BPM) becoming fully executable (and capable of [[round-trip engineering]]) is coming closer to reality every day. Supporting technologies include [[Unified Modeling Language]] (UML), [[model-driven architecture]], and [[service-oriented architecture]].
Process modeling addresses the process aspects of 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, organizational 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.
Line 34 ⟶ 35:
=== By coverage ===
There are five types of coverage where the term process model has been defined differently:<ref name="Dowson1988">M. Dowson (1998). ''Iteration in the Software Process, Proc 9th Int. Conf. on Software Engineering''.</ref>
*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.<ref name="Feiler1993">P.H. Feiler and [[W.S. Humphrey]]. (1993). ''Software Process Development and Enactment: Concepts and Definitions, Proc. 2nd Int. Conf. on "Software Process"''</ref>
* Product-oriented: series of activities that cause sensitive product transformations to reach the desired product.<ref name=Sianipar2014>
{{cite journal
Line 52 ⟶ 53:
|pages= 432–437
|url= http://morganasianipar.com/publication/physiological-concept-visible-modeling-feasible-design.html
|doi= 10.4028/www.scientific.net/AMM.493.432
|url-access= subscription
}}</ref>
* 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.
Line 73 ⟶ 76:
[[Granularity]] refers to the level of detail of a process model and affects the kind of guidance, explanation and trace that can be provided. Coarse granularity restricts these to a rather limited level of detail whereas fine granularity provides more detailed capability. The nature of granularity needed is dependent on the situation at hand.<ref name=Rolland1998/>
Project manager, customer representatives, the general, top-level, or middle management require rather coarse-grained process description as they want to gain an overview of 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 where the details of the model can provide 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 coarse-grained descriptions. Process models should, ideally, provide a wide range of granularity (e.g. Process Weaver).<ref name=Rolland1998/><ref name="Fernström1991">C. Fernström and L. Ohlsson (1991). ''Integration Needs in Process Enacted Environments, Proc. 1st Int. Conf. on the Software Process''. IEEE computer Society Press.</ref>
Line 84 ⟶ 87:
Method construction approaches can be organized in a flexibility spectrum ranging from 'low' to 'high'.<ref name=HBO/>
Lying at the 'low' end of this spectrum are rigid methods, whereas at the 'high' end there are 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. Selecting a rigid methods allows each project to choose its method from a panel of rigid, pre-defined methods, whereas selecting a path within a method consists of choosing the appropriate path for the situation at hand. Finally, selecting and tuning a method allows each project to select methods from different approaches and tune them to the project's needs."
== Quality of methods ==
Line 117 ⟶ 120:
Earliest process models reflected the dynamics of the process with a practical process obtained by instantiation in terms of relevant concepts, available technologies, specific implementation environments, process constraints and so on.<ref>Proceedings of the 9th international conference on Software Engineering</ref>
Enormous number of research has been done on quality of models but less focus has been shifted towards the quality of process models. Quality issues of process models cannot be evaluated exhaustively however there are four main guidelines and frameworks in practice for such. These are: top-down quality frameworks, bottom-up metrics related to quality aspects, empirical surveys related to modeling techniques, and pragmatic guidelines.<ref>{{cite journal |
Hommes quoted Wang ''et al.'' (1994)<ref name=ReferenceA/> that all the main characteristic of quality of models can all be grouped under 2 groups namely correctness and usefulness of a model, correctness ranges from the model correspondence to the phenomenon that is modeled to its correspondence to syntactical rules of the modeling and also it is independent of the purpose to which the model is used.
Line 125 ⟶ 128:
A common starting point for defining the quality of conceptual model is to look at the linguistic properties of the modeling language of which syntax and semantics are most often applied.
Also the broader approach is to be based on semiotics rather than linguistic as was done by Krogstie using the top-down quality framework known as SEQUAL.<ref name=krogstie/><ref>{{cite journal |
The framework does not however provide ways to determine various degrees of quality but has been used extensively for business process modeling in empirical tests carried out <ref>D. Moody, G. Sindre, T. Brasethvik and A. Sølvberg, Evaluating the quality of process models: empirical testing of a quality framework. In: S. Spaccapietra, S.T. March and Y. Kambayashi, Editors, Conceptual Modeling – ER 2002, 21st International Conference on Conceptual Modeling, Tampere, Finland, October 7–11, 2002, Proceedings, Lecture Notes in Computer Science vol. 2503, Springer (2002), pp. 380–396.</ref>
Line 147 ⟶ 150:
Finally, Participant Knowledge is the set of statements that human actors, who are involved in the modeling process, believe should be made to represent the problem ___domain. These quality dimensions were later divided into two groups that deal with physical and social aspects of the model.
In later work, Krogstie et al.<ref name=krogstie/> stated that while the extension of the [[SEQUAL framework]] has fixed some of the limitation of the initial framework, however other limitation remain .
In particular, the framework is too static in its view upon semantic quality, mainly considering models, not modeling activities, and comparing these models to a static ___domain rather than seeing the model as a facilitator for changing the ___domain.
Line 154 ⟶ 157:
The need for a more dynamic view in the semiotic quality framework is particularly evident when considering process models, which themselves often prescribe or even enact actions in the problem ___domain, hence a change to the model may also change the problem ___domain directly. This paper discusses the quality framework in relation to active process models and suggests a revised framework based on this.
Further work by Krogstie ''et al.'' (2006) to revise SEQUAL framework to be more appropriate for active process models by redefining physical quality with a more narrow interpretation than previous research.<ref name =krogstie>{{cite journal |
The other framework in use is Guidelines of Modeling (GoM) <ref>J. Becker, M. Rosemann and C. Uthmann, Guidelines of business process modeling. In: W. van der Aalst, J. Desel and A. Oberweis, Editors, Business Process Management. Models, Techniques, and Empirical Studies, Springer, Berlin (2000), pp. 30–49</ref> based on general accounting principles include the six principles: Correctness, Clarity deals with the comprehensibility and explicitness (System description) of model systems.
Line 167 ⟶ 170:
The use of bottom-up metrics related to quality aspects of process models is trying to bridge the gap of use of the other two frameworks by non-experts in modeling but it is mostly theoretical and no empirical tests have been carried out to support their use.
Most experiments carried out relate to the relationship between metrics and quality aspects and these works have been done individually by different authors: Canfora et al. study the connection mainly between count metrics (for example, the number of tasks or splits -and maintainability of software process models);<ref>{{cite journal |
The results reveal that an increase in size of a model appears to reduce its quality and comprehensibility.
Line 173 ⟶ 176:
Several empirical surveys carried out still do not give clear guidelines or ways of evaluating the quality of process models but it is necessary to have clear set of guidelines to guide modelers in this task. Pragmatic guidelines have been proposed by different practitioners even though it is difficult to provide an exhaustive account of such guidelines from practice.
Most of the guidelines are not easily put to practice but "label activities verb–noun" rule has been suggested by other practitioners before and analyzed empirically.
From the research.<ref>J. Mendling, H.A. Reijers, J. Recker, Activity Labeling in Process Modeling: Empirical Insights and Recommendations, Information Systems. URL: <http://eprints.qut.edu.au/19625/></ref> value of process models is not only dependent on the choice of graphical constructs but also on their annotation with textual labels which need to be analyzed. It was found that it results in better models in terms of understanding than alternative labelling styles.
Line 212 ⟶ 215:
| url = http://www.modelingconcepts.com/pdf/BPM_V2.pdf
| title = Abstraction Levels for Processes Presentation: Process Modeling Principles
| access-date = 2008-06-12
}}▼
| archive-url = https://web.archive.org/web/20110714110528/http://www.modelingconcepts.com/pdf/BPM_V2.pdf
| archive-date = 2011-07-14
| url-status = dead
▲ }}
* [http://www.apqc.org/ American Productivity and Quality Center (APQC)], a worldwide organization for process and performance improvement
* [http://www.workflowpatterns.com/documentation/documents/vanderaalst98application.pdf The Application of Petri Nets to Workflow Management], W.M.P. van der Aalst, 1998.
| |||