Content deleted Content added
Replaced a dead link with a more educational and relevant one. Tags: Reverted Visual edit |
Link suggestions feature: 3 links added. |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 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 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 75 ⟶ 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 149 ⟶ 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 210 ⟶ 211:
== External links ==
{{Commons category|Process diagrams}}
* [ftp://ftp.informatik.uni-stuttgart.de/pub/library/medoc.ustuttgart_fi/STUD-2052/STUD-2052.pdf Modeling processes regarding workflow patterns; link appears to be broken]{{dead link|date=April 2018 |bot=InternetArchiveBot |fix-attempted=yes }}
* {{cite web
| url = http://www.modelingconcepts.com/pdf/BPM_V2.pdf
Line 222:
* [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.
{{DEFAULTSORT:Process Modeling}}
[[Category:Business process management]]
|