This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
sysml-roadmap:model_lifecycle_management_working_group [2016-03-11 00:04] sfriedenthal |
sysml-roadmap:model_lifecycle_management_working_group [2016-12-25 10:43] (current) sfriedenthal |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | Back to [[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group| System Modeling Assessment and Roadmap Working Group]] | + | Back to [[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group| SysML v2 RFP Working Group]] |
Line 15: | Line 15: | ||
===== Project Overview ===== | ===== Project Overview ===== | ||
- | The Systems Engineering Model Lifecycle Management (MLM) project originated as a spinoff of the INCOSE MLM working group which originated in 2012 to indentify the scope and challenges of model management. Our focus here is to identify the capabilities (as services), and infrastructure needed to support a key aspect of MBSE Systems Modeling Environment (SME) namely, managaing the various model baselines. | + | The Systems Engineering Model Lifecycle Management (MLM) project originated as a spinoff of the [[http://www.omgwiki.org/MBSE/doku.php?id=mbse:modelmgt&do=| INCOSE MLM Working Group]] which originated in 2012 to indentify the scope and challenges of model management. Our focus here is to identify the capabilities (as services), and infrastructure needed to support a key aspect of MBSE Systems Modeling Environment (SME) namely, managaing the various model baselines. |
===== Model Lifecycle Management (MLM) Defined as ===== | ===== Model Lifecycle Management (MLM) Defined as ===== | ||
Line 26: | Line 26: | ||
* The next-generation modeling language must be capable of management in a heterogeneous and distributed modeling environment. The ability to manage change to the model, where multiple users are collaborating on a single model, is challenging enough. This basic capability requires extensive branch and merge capability that includes effective means for evaluating and integrating changes from multiple users, while maintaining a history of all changes. These challenges increase when multiple models and tools are all part of the collaboration. The ability to integrate with Product Lifecycle Management (PLM) environments, which enable versioning, configuration, and variant management, is a fundamental SME requirement. | * The next-generation modeling language must be capable of management in a heterogeneous and distributed modeling environment. The ability to manage change to the model, where multiple users are collaborating on a single model, is challenging enough. This basic capability requires extensive branch and merge capability that includes effective means for evaluating and integrating changes from multiple users, while maintaining a history of all changes. These challenges increase when multiple models and tools are all part of the collaboration. The ability to integrate with Product Lifecycle Management (PLM) environments, which enable versioning, configuration, and variant management, is a fundamental SME requirement. | ||
+ | ===== Performance: MoE - Measures of Effectiveness===== | ||
+ | |||
+ | * Scaleability (number of elements, uses, model size) | ||
+ | * Transaction Time (user transactions, bulk transactions) | ||
- | ===== Example Use Cases ===== | ||
- | * UC 1 Provide Actionable Data - A stakeholder of a Model/Model Element who is not the editor of the entire set of information within the Model/Model Element needs curated information within the model in order to make decisions or present definitive information to other parties. | ||
- | * UC 2 Provide Evidence/Provenance - During an exchange of information between parties engaged in argumentation, one party challenges the veracity of Model/Model Element information and the other party must obtain the provenance of the curated information in order to provide a warrant for the claims made by the information. | ||
- | * UC 3 Notify Users of Change - A stakeholder responsible for contributing to or curating numerous models has too little spare time to poll each model in their scope of responsibility; this stakeholder needs to be notified when an area of interest within a particular model is subject to access or modification by selected individuals or communities of interest. | ||
- | * UC 4 Collaborating on Model - Two or more stakeholders are collaborating on a common model yet are not present in the same actual meeting place. Lacking body language clues, the stakeholders need to receive indication of their peer activities within the shared model. | ||
- | * UC 5 Protect PI - A community of stakeholders with differing permissions to view, modify, and relate information form a joint venture that exploits their respective capabilities to solve a complex problem. Meanwhile, the providers of information retain their information confidentiality rights. | ||
- | * UC 6 Compare Models - An organization is requested to describe, present, or instantiate a system that was created some past time even perhaps with different knowledge tools and by individuals no longer associated with the organization. During such a representation, the organization is requested to demonstrate the differences between the current systems and the legacy systems. | ||
- | * UC 7 Support User Roles - An enterprise-scale team which aggregates functional and domain teams from a variety of corporations works contemporaneously and serially on a common problem that requires access to different model elements in different lifecycle phases, different levels of abstraction, in different disciplines, and with different information access rights. | ||
- | and more... | ||
- | |||
- | |||
- | ===== Status Quo ===== | ||
- | |||
- | * | ||
Line 129: | Line 119: | ||
* Broad support for model transformation | * Broad support for model transformation | ||
+ | ===== Example Use Cases ===== | ||
+ | * UC 1 Provide Actionable Data - A stakeholder of a Model/Model Element who is not the editor of the entire set of information within the Model/Model Element needs curated information within the model in order to make decisions or present definitive information to other parties. | ||
+ | * UC 2 Provide Evidence/Provenance - During an exchange of information between parties engaged in argumentation, one party challenges the veracity of Model/Model Element information and the other party must obtain the provenance of the curated information in order to provide a warrant for the claims made by the information. | ||
+ | * UC 3 Notify Users of Change - A stakeholder responsible for contributing to or curating numerous models has too little spare time to poll each model in their scope of responsibility; this stakeholder needs to be notified when an area of interest within a particular model is subject to access or modification by selected individuals or communities of interest. | ||
+ | * UC 4 Collaborating on Model - Two or more stakeholders are collaborating on a common model yet are not present in the same actual meeting place. Lacking body language clues, the stakeholders need to receive indication of their peer activities within the shared model. | ||
+ | * UC 5 Protect PI - A community of stakeholders with differing permissions to view, modify, and relate information form a joint venture that exploits their respective capabilities to solve a complex problem. Meanwhile, the providers of information retain their information confidentiality rights. | ||
+ | * UC 6 Compare Models - An organization is requested to describe, present, or instantiate a system that was created some past time even perhaps with different knowledge tools and by individuals no longer associated with the organization. During such a representation, the organization is requested to demonstrate the differences between the current systems and the legacy systems. | ||
+ | * UC 7 Support User Roles - An enterprise-scale team which aggregates functional and domain teams from a variety of corporations works contemporaneously and serially on a common problem that requires access to different model elements in different lifecycle phases, different levels of abstraction, in different disciplines, and with different information access rights. | ||
+ | |||
+ | and more... | ||
===== Recommended Standards for MLM ===== | ===== Recommended Standards for MLM ===== | ||
* | * | ||
Line 138: | Line 138: | ||
===== Review Documents ===== | ===== Review Documents ===== | ||
- | * | + | * [[http://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:model_lifecycle_management_for_mbse_v4.pdf|"Model Lifecycle Management for MBSE", Submitted version]] |
+ | * {{ :sysml-roadmap:system_model_management_ov1_8_dec_2016.pptx |SysML v2 Model Management OV-1 - draft Dec 12, 2016}} | ||
Line 192: | Line 193: | ||
===== Team ===== | ===== Team ===== | ||
^ Name ^ Organization ^ email ^ | ^ Name ^ Organization ^ email ^ | ||
- | | Laura E Hart| Lockheed Martin | <Laura.E.Hart@lmco.com> | | + | | Pavel Chadzynski| Aras | <[email protected]> | |
- | | Uwe Kaufmann| TBD | <tbd@tbd.com> | | + | | Laura E Hart| MITRE | <lhart@mitre.org> | |
- | | Mike Pfenning| TBD | <[email protected]> | | + | | Christian Muggeo| Technical University of Kaiserslautern | <muggeo@mv.uni-kl.de> | |
+ | | Uwe Kaufmann| ModelAlchemy Consulting| <uwe.kaufmann@modelalchemy.com> | | ||
+ | | Mike Pfenning| XPLM| <[email protected]> | | ||
- | Last updated February 17, 2016 | + | Last updated December 25, 2016 |