Content deleted Content added
Citation bot (talk | contribs) Add: s2cid, author pars. 1-1. Removed parameters. Some additions/deletions were actually parameter name changes. | You can use this bot yourself. Report bugs here. | Suggested by Abductive | All pages linked from cached copy of User:Abductive/sandbox | via #UCB_webform_linked 682/988 |
Link suggestions feature: 3 links added. |
||
| (8 intermediate revisions by 6 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 53 ⟶ 54:
|url= http://morganasianipar.com/publication/physiological-concept-visible-modeling-feasible-design.html
|doi= 10.4028/www.scientific.net/AMM.493.432|s2cid= 109776405
|url-access= subscription
}}</ref>
* Decision-oriented: set of related decisions conducted for the specific purpose of product definition.
Line 74 ⟶ 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 85 ⟶ 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 148 ⟶ 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 174 ⟶ 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.
| |||