Requirements for Model-Based Development Process Design and Compliance of Standardized Models
- The process model demonstrates an MBSE approach by its nature (i.e., includes visual representations of entities from a common data repository, designated for implementation as an IS), and thereby is representative of state-of-the-art approaches to addressing complexity;
- The process model is documented in a formal specification, which allows us to analyze the model definition objectively as well as attesting to its quality (such specifications are typically released after being thoroughly reviewed by experts, and embody significant domain expertise).
4. Requirements Set
4.1. Ontology of Development Process Design
- DPD shall involve the following entities for process composition: activity, artifact, and composite artifact-state.
- DPD shall support a qualitative, non-branching, procedural description of activities.
- DPD shall support detailing parallel activities.
- DPD shall allow for describing the additive/constructive perspective of development activities.
- DPD shall reflect a process scope.
- DPD shall encourage a hierarchical (multi-level) approach. Additionally, this further establishes that DPD shall support forward and backward consistency between the different hierarchies of a development plan.
- DPD shall be able to accommodate changes as well as uncertainty and purposeful creativity. Additionally, this further establishes that DPD shall incorporate a mechanism to allow control of the process, while offering degrees of freedom for its design.
4.2. Related Ontology of Process Models
- Process models shall, ideally, provide a wide range of granularity.
- Process models shall provide a mechanism to accommodate change.
- Development process models shall enable the reuse of elements of previous models that were used to design similar components or systems.
- Process model shall clearly correspond with related process ontology.
4.3. Model-Based DPD Requirements
- The DPD model shall include the following entities for process composition (activity, artifact, composite artifact-state [O1,M4]):
- Support Activity representation;
- Support Artifact representation;
- Support Composite Artifact-State representation.
- DPD model shall support a qualitative, procedural description of activities [O2, M4]:
- Support a procedural description of activities.
- DPD model shall support detailing parallel activities [O3, M4]:
- Detail parallel activities.
- DPD shall allow describing the additive/constructive perspective of development activities [O4, M4]:
- Describe the additive perspective of development activities.
- DPD model shall reflect process scope [O5, M4]:
- Reflect process scope.
- DPD model shall encourage hierarchical decomposition of a process, and provide consistency mechanisms [O6, M1]:
- Support consistent representations of process hierarchies.
- DPD model shall be able to accommodate changes as well as uncertainty [O7, M2]:
- Accommodate changes and uncertainty.
- DPD model shall allow, and preferably promote, reuse of previous models’ elements [M3]:
- Support reuse of previous models’ elements.
5. Evaluation of Modeling Approaches Compliance with DPD Model Requirements
5.1. OPM Evaluation for DPD
5.2. BPMN Evaluation for DPD
5.3. SPEM Evaluation for DPD
5.4. Models Evaluation Summary
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
- Atkinson, R. Project management: Cost, time and quality, two best guesses and a phenomenon, it’s time to accept other success criteria. Int. J. Project Manag. 1999, 17, 337–342. [Google Scholar] [CrossRef]
- White, D.; Fortune, J. Current practice in project management—An empirical study. Int. J. Proj. Manag. 2002, 20, 1–11. [Google Scholar] [CrossRef]
- Westerberg, A.W.; Subrahmainan, E.; Reich, Y.; Konda, S.; n-dim group. Designing the process design process. Comput. Chem. Eng. 1997, 21, S1–S9. [Google Scholar] [CrossRef]
- Millerand, F.; Baker, K.S. Who are the users? Who are the developers? Webs of users and developers in the development process of a technical standard. Inf. Syst. J. 2010, 20, 137–161. [Google Scholar] [CrossRef]
- Braha, D. The complexity of design networks: Structure and dynamics. In Experimental Design Research; Springer: Cham, Switzerland, 2016; pp. 129–151. [Google Scholar]
- Basili, V.R.; Rombach, H.D. Tailoring the software process to project goals and environments. In Proceedings of the 9th International Conference on Software Engineering, Washington, DC, USA, 30 March 1986; IEEE Computer Society Press: Washington, DC, USA, 1986; pp. 345–357. [Google Scholar]
- Goulielmos, M. Systems development approach: Transcending methodology. Inf. Syst. J. 2004, 14, 363–386. [Google Scholar] [CrossRef]
- Kalus, G.; Kuhrmann, M. Criteria for software process tailoring: A systematic review. In Proceedings of the 2013 International Conference on Software and System Process, San Francisco, CA, USA, 18–19 May 2013; ACM: New York, NY, USA, 2013; pp. 171–180. [Google Scholar]
- Locatelli, G.; Mancini, M.; Romano, E. Systems engineering to improve the governance in complex project environments. Int. J. Proj. Manag. 2014, 32, 1395–1410. [Google Scholar] [CrossRef]
- Robertson, L.J.; Abbas, R.; Alici, G.; Munoz, A.; Michael, K. Engineering-based design methodology for embedding ethics in autonomous robots. Proc. IEEE 2019, 107, 582–599. [Google Scholar] [CrossRef][Green Version]
- Gericke, K.; Qureshi, A.J.; Blessing, L. Analyzing transdisciplinary design processes in industry: An overview. In Proceedings of the ASME 2013 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Portland, OR, USA, 4–7 August 2013; American Society of Mechanical Engineers: New York, NY, USA, 2013; p. V005T06A031. [Google Scholar]
- Ramos, A.L.; Ferreira, J.V.; Barceló, J. Model-based systems engineering: An emerging approach for modern systems. IEEE Trans. Syst. Man Cybern. Part. C (Appl. Rev.) 2011, 42, 101–111. [Google Scholar] [CrossRef]
- Butler, T. Transforming information systems development through computer-aided systems engineering (CASE): Lessons from practice. Inf. Syst. J. 2000, 10, 167–193. [Google Scholar] [CrossRef]
- Bernal, M.; Haymaker, J.R.; Eastman, C. On the role of computational support for designers in action. Des. Stud. 2015, 41, 163–182. [Google Scholar] [CrossRef]
- Reich, Y. Life-cycle management of information and decisions for system analyses. Mech. Syst. Signal. Process. 2001, 15, 513–527. [Google Scholar] [CrossRef]
- Lyytinen, K.; King, J.L. Standard making: A critical research frontier for information systems research. MIS Q. 2006, 30, 405–411. [Google Scholar] [CrossRef][Green Version]
- Lowry, P.B. XML data mediation and collaboration: A proposed comprehensive architecture and query requirements for using XML to mediate heterogeneous data sources and targets. In Proceedings of the 34th Annual Hawaii International Conference on System Sciences, Maui, HI, USA, 3–6 January 2001; IEEE: Washington, DC, USA, 2001. [Google Scholar]
- Nishant, R.; Ravishankar, M.N. QCA and the harnessing of unstructured qualitative data. Inf. Syst. J. 2020. [Google Scholar] [CrossRef]
- McDermott, T.A.; Hutchison, N.; Clifford, M.; Van Aken, E.; Salado, A.; Henderson, K. Benchmarking the Benefits and Current Maturity of Model-Based Systems Engineering across the Enterprise; Technical Report SERC-2020-SR-001; Stevens Institute of Technology, Systems Engineering Research Center: Hoboken, NJ, USA, 2020; Available online: https://sercuarc.org/wp-content/uploads/2020/03/SERC-SR-2020-001-Benchmarking-the-Benefits-and-Current-Maturity-of-MBSE-3-2020.pdf (accessed on 11 January 2021).
- NIST. FIPS, Publication 183: Integration Definition of Function Modeling (IDEF0), National Institute of Standards and Technology 128. 1993. Available online: https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub183.pdf (accessed on 11 January 2021).
- Bork, D.; Karagiannis, D.; Pittl, B. A survey of modeling language specification techniques. Inf. Syst. 2020, 87, 101425. [Google Scholar] [CrossRef]
- OMG. BPMN 2.0—Formal Specification. 2011. Available online: https://www.omg.org/spec/BPMN/2.0/PDF (accessed on 11 January 2021).
- Van Der Aalst, W.M.; La Rosa, M.; Santoro, F.M. Business process management. Bus. Inf. Syst. Eng. 2016, 58, 1–6. [Google Scholar] [CrossRef][Green Version]
- Hobday, M.; Davies, A.; Prencipe, A. Systems integration: A core capability of the modern corporation. Ind. Corp Chang. 2005, 14, 1109–1143. [Google Scholar] [CrossRef]
- Gericke, K.; Blessing, L. Comparisons of design methodologies and process models across disciplines: A literature review. In Proceedings of the 18th International Conference on Engineering Design, Copenhagen, Denmark, 15–18 August 2011; Design Society: Glasgow, UK, 2011. [Google Scholar]
- Wynn, D.C.; Eckert, C.M.; Clarkson, P.J. Modelling iteration in engineering design. In Proceedings of the ICED 2007, the 16th International Conference on Engeneering Design, Paris, France, 28–31 July 2007; pp. 693–694. [Google Scholar]
- Münch, J.; Armbrust, O.; Soto, M.; Kowalczyk, M. Software Process Definition and Improvement; Fraunhofer: München, Germany, 2009. [Google Scholar]
- Recker, J.C.; zur Muehlen, M.; Siau, K.; Erickson, J.; Indulska, M. Measuring method complexity: UML versus BPMN. In Proceedings of the 15th Americas Conference on Information Systems, San Francisco, CA, USA, 6–9 August 2009. [Google Scholar]
- OMG. UML 2.5.1—Formal Specification. 2017. Available online: https://www.omg.org/spec/UML/2.5.1/PDF (accessed on 11 January 2021).
- Dijkman, R.M.; Dumas, M.; Ouyang, C. Semantics and analysis of business process models in BPMN. Inf. Softw. Technol. 2008, 50, 1281–1294. [Google Scholar] [CrossRef][Green Version]
- ISO. ISO/PAS 19450:2015—Automation Systems and Integration—Object-Process Methodology. 2015. Available online: https://www.iso.org/standard/62274.html (accessed on 11 January 2021).
- Sharon, A.; de Weck, O.L.; Dori, D. Is There a Complete Project Plan? A Model-Based Project Planning Approach. In Proceedings of the INCOSE International Symposium, Singapore, 20–23 July 2009; Volume 19, pp. 96–109. [Google Scholar]
- Sitton, M.; Reich, Y. ESE Framework Verification by MBSE. IEEE Syst. J. 2018, 13, 2108–2117. [Google Scholar] [CrossRef]
- Li, L.; Soskin, N.L.; Jbara, A.; Karpel, M.; Dori, D. Model-Based Systems Engineering for Aircraft Design with Dynamic Landing Constraints Using Object-Process Methodology. IEEE Access 2019, 7, 61494–61511. [Google Scholar] [CrossRef]
- Sharon, A.; de Weck, O.L.; Dori, D. Improving Project–Product Lifecycle Management with Model–Based Design Structure Matrix: A joint project management and systems engineering approach. Syst. Eng. 2013, 16, 413–426. [Google Scholar] [CrossRef]
- OMG. Software Process Engineering Metamodel Specification, Version 1.0, formal/02–11-14. 2002. Available online: https://www.omg.org/spec/SPEM/1.0/PDF (accessed on 11 January 2021).
- OMG. Software & Systems Process Engineering Meta-Model Specification, Version 2.0, formal/2008-04-01. 2008. Available online: https://www.omg.org/spec/SPEM/2.0/PDF (accessed on 11 January 2021).
- Bendraou, R.; Jezequel, J.M.; Gervais, M.P.; Blanc, X. A comparison of six UML-based languages for software process modeling. IEEE Trans. Softw. Eng. 2010, 36, 662–675. [Google Scholar] [CrossRef][Green Version]
- Ruiz-Rube, I.; Dodero, J.M.; Palomo-Duarte, M.; Ruiz, M.; Gawn, D. Uses and applications of SPEM process models. A systematic mapping study. J. Softw. Maint. Evol. Res. Pract. 2012, 1, 999–1025. [Google Scholar]
- Kuhrmann, M.; Kalus, G.; Wachtel, E.; Broy, M. Visual process model design using domain-specific languages. In Proceedings of the SPLASH Workshop on Flexible Modeling Tools, Reno, NV, USA, 18 October 2010; Volume 2010. [Google Scholar]
- Wand, Y.; Weber, R. On the ontological expressiveness of information systems analysis and design grammars. Inf. Syst. J. 1993, 3, 217–237. [Google Scholar] [CrossRef]
- Yang, L.; Cormican, K.; Yu, M. Ontology-based systems engineering: A state-of-the-art review. Comput. Ind. 2019, 111, 148–171. [Google Scholar] [CrossRef]
- Browning, T.R. Process integration using the design structure matrix. Syst. Eng. 2002, 5, 180–193. [Google Scholar] [CrossRef]
- Browning, T.R. Building models of product development processes: An integrative approach to managing organizational knowledge. Syst. Eng. 2018, 21, 70–87. [Google Scholar] [CrossRef]
- Goetschalckx, M. Supply Chain Engineering; Springer Science & Business Media: Berlin/Heidelberg, Germany, 2011; Volume 161. [Google Scholar]
- Dori, D.; Linchevski, C.; Manor, R. OPCAT–An Object-Process CASE Tool for OPM-Based Conceptual Modelling. In Proceedings of the 1st International Conference on Modelling and Management of Engineering Processes, Cambridge, UK, 19–20 July 2010; pp. 1–30. [Google Scholar]
- Simon, H.A. The Architecture of Complexity. Proc. Am. Philos. Soc. 1962, 106, 467–482. [Google Scholar]
- Eckert, C.M.; Clarkson, P.J. Planning development processes for complex products. Res. Eng. Des. 2010, 21, 153–171. [Google Scholar] [CrossRef]
- Hällgren, M.; Wilson, T.L. Mini-muddling: Learning from project plan deviations. J. Workplace Learn. 2007, 19, 92–107. [Google Scholar] [CrossRef]
- Gericke, K.; Blessing, L. An analysis of design process models across disciplines. In Proceedings of the DS 70: Proceedings of DESIGN 2012, the 12th International Design Conference, Dubrovnik, Croatia, 6 May 2012. [Google Scholar]
- Davis, A.M.; Sitaram, P. A concurrent process model of software development. ACM SIGSOFT Softw. Eng. Notes 1994, 19, 38–51. [Google Scholar] [CrossRef]
- Spillner, A.; Bremenn, H. The W-MODEL. Strengthening the bond between development and test. In Proceedings of the International Conferences on Software Testing, Analysis and Review, Roma, Italy, 22–24 July 2002; pp. 15–17. [Google Scholar]
- Shaked, A.; Reich, Y. Designing development processes related to system of systems using a modeling framework. Syst. Eng. 2019, 22, 561–575. [Google Scholar] [CrossRef]
- Shaked, A.; Reich, Y. Improving Coordination and Collaboration in Connected and Automated Vehicle Development Projects Using Model Based Process Design (No. 2019-01-0103). SAE: Warrendale, PA, USA, 2019. [CrossRef]
- Shaked, A.; Reich, Y. Improving Process Descriptions in Research by Model-Based Analysis. IEEE Syst. J. 2020. [Google Scholar] [CrossRef]
- Cooper, R.G.; Kleinschmidt, E.J. Winning businesses in product development: The critical success factors. Res. Technol. Manag. 2007, 50, 52–66. [Google Scholar] [CrossRef]
- Mendling, J.; Neumann, G.; Van Der Aalst, W. Understanding the occurrence of errors in process models based on metrics. In Proceedings of the OTM Confederated International Conferences on the Move to Meaningful Internet Systems, Vilamoura, Portugal, 25–30 November 2007; Springer: Berlin/Heidelberg, Germany, 2007; pp. 113–130. [Google Scholar]
- Reijers, H.; Mendling, J. Modularity in process models: Review and effects. In International Conference on Business Process Managemen, Milan, Italy, 2–4 September 2008; Springer: Berlin/Heidelberg, Germany, 2008; pp. 20–35. [Google Scholar]
- Karniel, A.; Reich, Y. Multi-level modelling and simulation of new product development processes. J. Eng. Des. 2013, 24, 185–210. [Google Scholar] [CrossRef]
- Rolland, C. A comprehensive view of process engineering. In Proceedings of the International Conference on Advanced Information Systems Engineering, Rome, Italy, 3–7 June 1998; Springer: Berlin/Heidelberg, Germany, 1998; pp. 1–24. [Google Scholar]
- Aharoni, A.; Reinhartz-Berger, I. A domain engineering approach for situational method engineering. In Proceedings of the International Conference on Conceptual Modeling, Barcelona, Spain, 20–24 October 2008; Springer: Berlin/Heidelberg, Germany, 2008; pp. 455–468. [Google Scholar]
- Soffer, P.; Golany, B.; Dori, D.; Wand, Y. Modelling off-the-shelf information systems requirements: An ontological approach. Requir. Eng. 2001, 6, 183–199. [Google Scholar] [CrossRef]
- Dori, D.; Reinhartz-Berger, I. An OPM-based metamodel of system development process. In Proceedings of the Conference on Conceptual Modeling, Chicago, IL, USA, 13–16 October 2003; Springer: Berlin/Heidelberg, Germany, 2003; pp. 105–117. [Google Scholar]
- Reinhartz-Berger, I. Representation of situational methods: Incorporating ISO/IEC 24774 into a domain-based framework. Int. J. Inf. Syst. Modeling Des. 2013, 4, 32–49. [Google Scholar] [CrossRef][Green Version]
- Owen, M.; Raj, J. BPMN and Business Process Management, Introduction to the New Business Process Modeling Standard; Popkin Software. 2003. Available online: https://www.omg.org/bpmn/Documents/6AD5D16960.BPMN_and_BPM.pdf (accessed on 11 January 2021).
- Rosemann, M.; Recker, J.C.; Flender, C. Contextualisation of business processes. Int. J. Bus. Process. Integr. Manag. 2008, 3, 47–60. [Google Scholar] [CrossRef][Green Version]
- Recker, J.C.; Indulska, M.; Rosemann, M.; Green, P. How good is BPMN really? Insights from theory and practice. In Proceedings of the 14th European Conference on Information Systems, Goeteborg, Sweden, 12–14 June 2006. [Google Scholar]
- Gonzalez-Perez, C. Supporting situational method engineering with ISO/IEC 24744 and the work product pool approach. In Working Conference on Method Engineering; Springer: Boston, MA, USA, 2007; pp. 7–18. [Google Scholar]
- Martınez-Ruiz, T.; Garcıa, F.; Piattini, M.; Münch, J. Modelling software process variability: An empirical study. IET Softw. 2011, 5, 172–187. [Google Scholar] [CrossRef]
- Aoussat, F.; Oussalah, M.; Nacer, M.A. SPEM Extension with software process architectural concepts. In Proceedings of the 2011 IEEE 35th Annual Computer Software and Applications Conference, Munich, Germany, 18–22 July 2011; pp. 215–223. [Google Scholar]
- Pagliares, R.M.; Hirata, C.M. Mapping SPEM process specifications to activity cycle diagrams. Int. J. Simul. Model. 2018, 17, 55–68. [Google Scholar] [CrossRef]
- Seidita, V.; Cossentino, M.; Gaglio, S. Using and extending the SPEM specifications to represent agent oriented methodologies. In International Workshop on Agent-Oriented Software Engineering; Springer: Berlin/Heidelberg, Germany, 2008; pp. 46–59. [Google Scholar]
- Steghöfer, J.P. Using Essence in a Software Development Methodologies Course: An Experience Report. In Proceedings of the ISEE 2019: 2nd Workshop on Innovative Software Engineering Education, Stuttgart, Germany, 19 February 2019; pp. 7–10. [Google Scholar]
The explanation here is a slight adaptation of the description offered by the Modelling and Management of Engineering Processes Special Interest Group of the Design Society, as reported in .
There are MBSE languages that are designated for other purposes, and are therefore not considered here. For example, SysML (systems modeling language) was devised for the engineering of a technical system, and not for engineering processes. We focus on languages that are specifically designed to address the design of processes (such as BPMN and SPEM—introduced shortly; developed by the same standards consortium responsible for SysML). Unlike SysML, OPM is a general conceptual modeling approach, designed with a significant focus on processes (P stands for process).
This current version reinterprets SPEM as “Software & Systems Process Engineering Meta-Model” , without explaining the addition of “Systems.” Systems, in general, may have characteristics that are different from those of software systems (see, for example, [12)], and therefore such a generalization is not to be made lightheadedly.
However, Browning’s concept relates to the attributes as stationary, not taking into account the evolution of the artifact throughout the development (discussed shortly).
Interestingly, this important ontological observation is not reflected in SPEM design: immediately after this key observation is mentioned, only “role,” “activity” and “work product” are identified as model elements (omitting “state”). Furthermore, in the current version of the specification (2.0), this ontological observation is entirely missing.
Consequently, this results in miscommunication and poor coordination, which leads to poor cooperation, rework and trouble in development efforts.
Paradoxically, in the same publication, the authors acknowledge that design processes are unlike workflow-based processes.
Browning further stresses that not all development related activities should be incorporated into a process plan, and specifically mentions that general infrastructure activities are best left out. Overall, we agree with this approach.
These requirements are high-level functional requirements, and can be elaborated with both lower-level functional requirements and non-functional, performance-related requirements. Since our goal here is to develop and discuss DPD modeling concepts, this level of requirements should be sufficient, and whenever we feel it is appropriate, we provide a discussion with respect to lower-level details.
As in the agreement, the OPM standard  does not mention “reuse” at all.
This is not trivial. The UML standard  specifies “State Invariant” as a constraint evaluated at runtime (i.e., with respect to our domain, it is not evaluated upon design/analysis). The UML standard considers “State Invariant” model entity as an “InteractionFragment” entity to be placed on a lifeline (within an activity diagram), and this is also the only mechanism of using this element shown in the UML specification. A SPEM brief example of using such an element shows an unspecified extension of the UML meta-model.
This recommendation does not promote the desired SE approach to DPD, as it does not include artifact-related data. The specification also mentions that this approach is “utilized by popular project planning tools,” further attesting to its managerial perspective origin.
SPEM acknowledges the need to perform tailoring for specific project situations, and provides mechanisms that support tailoring for “method content” and “process patterns.” These, however, require high user proficiency, and do not accommodate changes.
Process component usage is depicted for some specific situations (mostly for encapsulation of work), and is not encouraged or described sufficiently to be used as a general design paradigm. Furthermore, the description of the associated “invariant” modeling entity is insufficient; especially considering that its use is an extension of the UML standard , which remains undefined. Accordingly, we found that a leading MBSE commercial tool that is SPEM 2.0-compliant—Sparx Enterprise Architect—does not support this.
|0||The model does not comply with the requirement.|
|1||The model includes basic support for complying with the requirement, yet significant elaboration and/or alteration is required. Specifically, this score is used whenever relevant modeling constructs can be composed from constructs specified by the model, yet this is prone to user preference and/or requires high expertise. This score may also reflect the lack of a modeling method to support the modeling with respect to the requirement, typically resulting in a cognitive burden on the user, and consequently in idiosyncratic models.|
|2||The model implicitly addresses the concept represented by the requirement, yet, it does not specify and/or facilitate rigorous use to support the concept. Specifically, this score is used whenever a model permits multiple semantically distinguished representations of the concept, and/or requires the modeler to select from multiple modeling patterns in order to model a domain-related pattern.|
|3||The model explicitly addresses the concept represented by the requirement and/or fully complies with its content. The modeling patterns map to the domain-related patterns with one-to-one correspondence (i.e., there is a bijective function between modeling patterns and domain-related patterns).|
|Requirement||Model Support Score||Brief Reasoning|
|REQ1 Support Activity representation||3||“Process” element|
|REQ2 Support Artifact representation||3||“Object” element|
|REQ3 Support Composite Artifact-State representation||1||A “state” modeling element exists, but no inherent method to support a composite state of the artifact, as OPM allows an object to be in one state at a specific time. In addition, OPM accepts an alleviative approach that does not necessitate using state designations in process descriptions.|
|REQ4 Support a procedural description of activities||1||A sense of flow/orientation can be established, but is not a focus of the model. An implicit arrangement of activities (top to bottom) can be used to depict their order of execution, but this is used primarily for simulation purposes (and, in turn, risks the ability to simulate concurrent activities).|
|REQ5 Detail parallel activities||3||Activities can be modeled regardless of execution order.|
|REQ6 Describe the additive perspective of development activities||0||No inherent support.|
|REQ7 Reflect process scope||1||Process scope may be established manually, but is not self-contained within a representation and/or emerges out of the representation.|
|REQ8 Support consistent representations of process hierarchies||2||Multi-level representation of the process hierarchies is available via diagrams “in-zooming” and “unfolding”, but no consistency is assured. For example, the “in-zooming” diagram is used to present two hierarchies of the process (the process and its sub-processes), and allows to model relations between sub-processes and external entities without requiring these relations to be specified in the higher, process level hierarchy. Specifically, forward and backward consistency is hindered by support of dissimilar relationships in various levels of hierarchies.|
|REQ9 Accommodate changes and uncertainty||2||OPM supports encapsulation for processes. However, its encapsulation does not seem to be rigorous enough, and may be open to interpretations. Furthermore, OPM does not promote consistency between diagrams of different hierarchies: when changing links for an activity in one hierarchy, its lower and/or higher hierarchies are indifferent to the change.|
|REQ10 Support reuse of previous models||0||No DPD modeling method exists, and this results in idiosyncratic process models. In turn, this hinders reuse of elements from previous models, especially since they are not available as a self-contained representation.|
|Requirement||Model Support Score||Brief Reasoning|
|REQ1 Support Activity representation||2||“Activity” element exists. However, there are redundant representations of activities in the form of “Sub-process” (for non-atomic activities) and “Task” (for atomic activities), which are considered extended elements. |
Additional elements may hinder correct modeling: “Group”
Task Types: “Service Task”, “Send Task”, “Receive Task”, “User Task”, “Manual Task”, “Business Role Task”, “Script Task”, “Call Activity”
Sub-process Types: “Transaction Sub-Process”, “Ad-Hoc Sub-Process”, “Call Activity”
|REQ2 Support Artifact representation||3||“Data Object” element exists.|
|REQ3 Support Composite Artifact-State representation||0||BPMN allows only a single state (using the optional “dataState” attribute) to be attached to a data object element. There is no inherent support for artifact’s composite state representation.|
|REQ4 Support a procedural description of activities||3||A sense of flow/orientation can be established, using flow elements.|
|REQ5 Detail parallel activities||3||Supported. This is explicitly identified as one use case of using “Sub-process” entities.|
|REQ6 Describe the additive perspective of development activities||0||No inherent support. Artifacts are considered optional.|
|REQ7 Reflect process scope||1||Process scopes may be established, and are hierarchically nested. A scope is defined by the specification as a set of data objects available, events and conversation. However, the graphical notation does not reflect the scope (especially with respect to data objects), and the model seems to relate to the scope as an execution mechanism rather than a design mechanism.|
“Sub-process” modeling entities are explicitly mentioned as a mechanism to design a contextual scope, but this does not relate to artifacts in the establishing of such scope. Specifically, activities (“sub-process”/“task”) may implicitly use artifacts (“data object”) of higher hierarchies, hindering understanding of their real scope.
|REQ8 Support consistent representations of process hierarchies||2||Multi-level representation of process hierarchies is available (using “Sub-process” entities), but no consistency issues are addressed.|
|REQ9 Accommodate changes and uncertainty||1||“Task” entities may be used to accommodate uncertainty. The models, however, exhibit low tolerance to changes, and specifically do not methodically address the propagation of changes.|
|REQ10 Support reuse of previous models||1||A process can refer to another process via the “Call Activity” mechanism, yet this “black box” call to a process does not contribute to a disciplined process design. No DPD modeling method exists, resulting in idiosyncratic models. In turn, this hinders the reuse of segments from previous models.|
|Requirement||Model Support Score||Brief Reasoning|
|REQ1 Support Activity representation||2||“Activity” element (a “Work Definition”-derived entity).|
Potential redundancies: “Milestone”; other “Work Definition”-derived entities: “TaskDefinition”, “Step”, “Task Use”, “ProcessComponent”, “ProcessComponentUse”
|REQ2 Support Artifact representation||2||“Work Product Definition”|
“Work Product Use” element. This element is an activity-specific object, and therefore does not support artifacts outside of activities.
|REQ3 Support Composite Artifact-State representation||1||States can be detailed explicitly (extending UML state machines and activity diagrams to support this). However, there is no inherent mechanism for artifact composite state representation.|
|REQ4 Support a procedural description of activities||1||A sense of flow/orientation can be established. The abundance of entities, relations and diagrams, however, significantly hinders such description. The standard acknowledges that the UML-derived representation is not practical, and suggests a structured tabular, textual representation (“Work Breakdown Structure Presentation”) to be used instead. The tabular representation does not facilitate process orientation.|
|REQ5 Detail parallel activities||2||SPEM supports and encourages the modeling of activities regardless of execution order. However, it seems that process design is somewhat left to enactment itself (which is out of the scope of SPEM methodology) to make such design decisions.|
|REQ6 Describe the additive perspective of development activities||0||No real methodology concerning this, but rather a collection of various, alternative mechanisms. UML-based state transitions, various implementations of activity diagram, and attributes of both activity and artifact elements may be used, promoting idiosyncratic modeling.|
|REQ7 Reflect process scope||1||A partial process scope may be established manually (by analysis of models/representations), but is not self-contained within a representation and/or emerges out of a representation. Additionally, leaving out some design decisions to process enactment reduces the ability to recognize scope.|
ProcessComponent provides a good scoping mechanism for encapsulation. However, it does not facilitate the rigorous definition of artifacts (one example does refer to the use of a UML “state invariant” element to depict such states14), and no proper methodological attention is given to such use of scoping (reading the standard, ProcessComponent is given a limited attention). Furthermore, the specification strangely states that this element contains “exactly one Process that is physically encapsulated.”
|REQ8 Support consistent representations of process hierarchies||2||Multi-level representation of process hierarchies is limited, and concentrates mainly on a breakdown structure mechanism to define the organization of methods and activities (including tasks and steps, which are not interchangeable). Consistency is not assured.|
ProcessComponent may provide a good mechanism for this; but its use needs to be detailed to provide rigorous use of this element.
|REQ9 Accommodate changes and uncertainty||1||A separation between method content and its complex reuse mechanism (e.g., various element types) for process design hinders model changes.|
While “Activity” element was conceived for supporting uncertainty (or self-organizing teams, in the domain of software engineering for which SPEM was developed), the details of reusable methods (specifically “task” and “step”) reduce the ability to accommodate uncertainty.
“Process Component” provides a good encapsulation mechanism, but is designated by the standard for use in situations of delegation or undecided black-box activity (and not as a hierarchical, SADT-like process design mechanism).
|REQ10 Support reuse of previous models||1||Reuse of method content is encouraged, provided it is fully reused; with mostly the sequence of using method content left as a degree of freedom, for a specific project design.|
The separation between method content and actual process composition hinders the post-completion reuse of performed activities design as future method content. The details of reusable methods and the redundant definitions may hinder their effective reuse, especially in different hierarchies.
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.
© 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Share and Cite
Shaked, A.; Reich, Y. Requirements for Model-Based Development Process Design and Compliance of Standardized Models. Systems 2021, 9, 3. https://doi.org/10.3390/systems9010003
Shaked A, Reich Y. Requirements for Model-Based Development Process Design and Compliance of Standardized Models. Systems. 2021; 9(1):3. https://doi.org/10.3390/systems9010003Chicago/Turabian Style
Shaked, Avi, and Yoram Reich. 2021. "Requirements for Model-Based Development Process Design and Compliance of Standardized Models" Systems 9, no. 1: 3. https://doi.org/10.3390/systems9010003