Content deleted Content added
unreliable source |
Link suggestions feature: 3 links added. |
||
| (7 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.
| |||