Model quality
How well do your models conform to the Method & Style guidelines? Benchmark your models with some best practice quality measures!
The quality of your models depends highly on the goals you set for your model. One goal every modeler shares is clearly the readability of his BPMN models. Process Modeler supports you with the principles for good modeling:
- Correctness
- Relevance
- Efficiency
- Clearness
- Comparability
- Good composition
Applying the quality benchmarks and, of course, reviewing the above principles, will lead you to well-defined, consistent, complete and readable models.
Quality measures can be divided into three sections and cover a vast range of statistics. Below you get an introduction into these measures:
The measures are divided into 5 categories:
Violations
Here you get statistices to violations against the BPMN specification and Method and Style, and the number of recommendations and tips about your model.
| Name | Description | Objective of the measure | Relevance for total quality |
|---|---|---|---|
| Number of Method&Style violations | Method & Style rules claim for readable and consistent diagrams. Tip for creating good models: Try to eliminate all Method & Style violations. | If 0, then status = green If > 0 then status = red | yes |
| Number of errors | The BPMN specification defines rules for each element you use. Thus, in order to get a model that is understood by the majority of reader, you need to comply with the rules of BPMN. Tip for creating good models: Eliminate each and every violation against the spec. | If 0, then status = green If >0 then status = red | yes |
| Number of warnings | There are some grey areas in the specification of BPMN. Warnings should make you aware if you used patterns that are not clearly defined. Tip for creating good models: Try to model patterns that have only one meaning. | If 0, then status = green If 1 - 5 warnings, then status = orange If > 5, then status = red | yes |
| Number of information items | Informations (with the blue information icon) are recomendations which you may use or not. Tip for creating good models: Your organisation needs to define modeling conventions in which you define what patterns/elements have to be used and which not. | no colour | no |
Complexity
Complexity measures show how complex, i.e. how difficult to read, your model is. They can help you to simplify the model.
| Name | Description | Objective of the measure | Relevance for total quality |
|---|---|---|---|
| Number of start events（Max: 5 | The number of start events on the main level should not get too high. Otherwise, the diagram is unreadable. Many different starting points may indicate too much fragmentation of the diagram. Note: Keep the number of start events under 5. | Number of start events > 5 = orange Else = green | yes |
| Number of activities per process level (Min: 5, Max: 10) | For a simple diagram any process level should contain 9 activities at most but not less than 5. The hierarchical style let's you to compress details into sub-processes. Good application of hierarchical modeling style helps the reader to understand models easily. Note: Try to define a useful set of no more than 9 main activities (sub-processes). | Optimal number of activities < 10 and >5 If number of activities > 15, then red Falls Anzahl Prozessebenen mit zuvielen oder zu wenigen Aktivitäten > 3 = Rot Sonst Falls Anzahl Prozessebenen mit zuvielen oder zu wenigen Aktivitäten > 0 = Orange Sonst Grün | yes |
| Number of sub-levels (model depth max: 3) | A BPMN process is unreadable if too many sub-levels are defined. Possible reasons for too many sub-levels: The top-level is set too high, model hierarchy is defined too steep (too many small levels), or the model is specified too detailed.. Note: If you defined more than 3 sub-levels, you should consider how the model can be divided more clearly and whether too many details have been modeled. | If model depth <=3 then status = Grün If model depth >3 und <=5 dann status = orange If model depth >6 then status = red | yes |
| Number of gateways on the top-level | The top-level of a model gives an overview to the process and should therefore be easily understood (according to the addressed reader). A large number of gateways suggests that too many exception paths are shown at the top-level. Note: Draw only the most important exceptions on the top-level. | Keep a well-arranged number of gateways | no |
| Number of gateways with more than 5 outgoing paths | The top-level of a model gives an overview to the process and should therefore be easily understood (according to the addressed reader). A large number of gateways suggests that too many exception paths are shown at the top-level. Note: Many gateways and many exception paths may indicate that a business rule-oriented language is required. Ensure on the other hand that decisions can be easily read (eg using Boolean queries) | Only show as much gates as relevant for the continuation of the process. | no |
| Number of black-box pools | Black box pools show processes and participants that interact with the modeled process. Again, consider the principles of the relevance and importance. Note: Do not model each and every partner of a process, but only those which are necessary in order to understand the process. Your diagram is hard to understand if the sheet has too many pools. | Only show relevant black-box pools. | no |
Consistency
At the end of you modeling process you want to get consistent diagrams. Consistency measures suggest where the diagram is missing information.
| Name | Description | Objective of the measure | Relevance for total quality |
|---|---|---|---|
| Number of non-connected sub-processes | Sub-processes are used for hierarchical structuring process details. Thus, a sub-process indicates that more details can be found. Note: A model is "underspecified" i.e. not complete if sub-processes are empty or do not reference their details. | Measured values: Number of not specified sub-processes Number of non-referencing call activities Benchmark: Number of both values = 0 then status = green Number of both values > 0 and < 10 then status = orange Number of both values > 10 then status = red | yes |
| Number of non-connected call activities | Call activities are used for lean modelling of processes. A call activity references a reusable process step that has to be defined at a central place. Note: A model is "underspecified" i.e. not complete if call activities do not reference their details. | Measured values: Number of not specified sub-processes Number of non-referencing call activities Benchmark: Number of both values = 0 then status = green Number of both values > 0 and < 10 then status = orange Number of both values > 10 then status = red | yes |
| Number of start events in relation to end events | If a process is initiated by the message of an external participant, typically this participant is notified when the process is finished. This is usually drawn by a message end event. | If at least 1 message start event and at least 1 message end event then status = green If there is a message start event and no message end event, then status = orange | yes |
| Number of tasks with specified/unspecified type | By specifying a tasks you show how this task is performed. If you do this, remind to specify this for every task. If you only specify some but don't do it for others then your model seems to be incomplete. Note: A model is underspecified if some tasks have types and other not. | One value (number of specified/unspecified tasks) should be zero. | no |
| Number of data object references that only read/write | If data object are used (read) by an activity they have to be instantiated within the same process. The instance of a data object limits to one cycle of a process. Note: Data objects (and data object references) should be written in the same model as they are read. | For each data object reference there sould be at least one writing data association. | no |
| Number of unlabeled data objects | Data objects are elements that are defined in the hidden XML but indicated by visible data object references. So more data object references can relate to one data object. You have to define/specify all of these data objects in the back ground (using the attribute dialog of data object references). Note: A model seems to be underspecified if data objects are not described. | Keep the number of unlabeled data stores equal to 0. | no |
| Number of unlabeled data stores | Data stores are elements that are defined in the hidden XML but indicated by visible data store references. So more data store references can relate to one data store. You have to define/specify all of these data stores in the back ground (using the attribute dialog of data store references). Note: A model seems to be underspecified if data stores are not described. | Keep the number of unlabeled data stores equal to 0. | no |
| Number of activities that are not assigned to a lane | Lanes can be used to depict the responsibility of tasks. Note: If you use lanes mind to assign every task to one lane. | If there is one or more lane, every task should be assigned to a lane. | no |
Vagueness
BPMN enables you to precisely define your business process. If you are working on a highly standardized or frequently instantiated process you can make use of that and avoid using freely definable elements (as for example ad-hoc sub-process). Only use those elements if they are really appropriate. The measures of vagueness help you to estimate how precise you defined a business process.
| Name | Description | Objective of the measure | Relevance for total quality |
|---|---|---|---|
| Ratio between flow elements with comments/all flow elements (max. 3%) | A model seems to require a lot of explications if you allocate much comments. Some of them could be transferred to the documentation attributes other should be modeled with process flow and logic. Iterative activities (loop, parallel) and complex gateways require a comment so the reader understands its logic. Note: Keep the number of comments to a minimum. | If 0 and <= 0.03 (3%) then status = green If >0.03 and <= 0.1 (10%) then status = orange If > 0.1 then status = red | yes |
| Number of inclusive and complex gateways | A large number of OR and complex gateways indicate that a model is hold vague. It is probable that the process logic can be defined more precisely or clearly by using XOR gateways. Note: Just use inclusive and exclusive gateways where required. | Keep the number of gateway that need more explanations low. | no |
| Number of tasks with more than 3 message flows | A large number of message flows on a task indicates that more details of that task could/should be modeled withing a sub-process. Otherwise it could indicate too much detail of interaction. Note: Only show those message flows that are really required for understandign process flow. | Keep the number of message flows per task low. | no |
Others
This category shows you some measures which are of statistical nature.
| Name | Description | Objective of the measure | Relevance for total quality |
|---|---|---|---|
| Number of related documents | This measure is only of statistical nature. | Make visible how deep a process is documented. | no |