sysml-roadmap:model_lifecycle_management_working_group
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
sysml-roadmap:model_lifecycle_management_working_group [2016-02-24 06:24] lhart |
sysml-roadmap:model_lifecycle_management_working_group [2016-12-25 10:36] sfriedenthal [Review Documents] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | Back to [[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group| SysML Assessment and Roadmap Working Group]] | + | 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]] |
| Line 6: | Line 6: | ||
| ====== Systems Engineering Model Lifecycle Management (MLM) Workgroup ====== | ====== Systems Engineering Model Lifecycle Management (MLM) Workgroup ====== | ||
| + | |||
| Line 14: | 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, 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 24: | Line 25: | ||
| * 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 47: | Line 41: | ||
| ===== Limitations of SysML ===== | ===== Limitations of SysML ===== | ||
| - | SysML data currently not available: | + | SysML meta data/concepts currently not available in the language: |
| - | * native versioning data | + | * Time of revision |
| + | * System identification (which system is being modeled) | ||
| + | * Model version identification | ||
| + | * Previous model version identification | ||
| + | * Dependency information to other MCI’s and modeling artifacts | ||
| + | * Author information | ||
| + | * Tool/Environment version information | ||
| + | * External sources | ||
| + | * Rationale and assumptions | ||
| + | * Variances and feature lists | ||
| ===== Derived Requirements ===== | ===== Derived Requirements ===== | ||
| Line 68: | Line 70: | ||
| - The MLMS shall provide services to identify different versions of a MCI and related artifacts, and maintain a history of the versions | - The MLMS shall provide services to identify different versions of a MCI and related artifacts, and maintain a history of the versions | ||
| - The MLMS shall provide services to identify different variations of an MCI and related artifacts, and maintain a lineage of the variations (e.g., their source and dependencies) | - The MLMS shall provide services to identify different variations of an MCI and related artifacts, and maintain a lineage of the variations (e.g., their source and dependencies) | ||
| - | - 8The MLMS shall provide services to generate reports of the differences between versions and variants of MCI’s or collections of MCI’s (include comparison of MCI’s resulting from different tool versions) | + | - The MLMS shall provide services to generate reports of the differences between versions and variants of MCI’s or collections of MCI’s (include comparison of MCI’s resulting from different tool versions) |
| - | - 9The MLMS shall provide services to manage dependencies between versions and variants of MCI’s that may be the same or different model kind. The management shall include: | + | - The MLMS shall provide services to manage dependencies between versions and variants of MCI’s that may be the same or different model kind. The management shall include: |
| -- Create and identify a dependency | -- Create and identify a dependency | ||
| -- Delete a dependency | -- Delete a dependency | ||
| -- Generate a query/report of the dependencies between an MCI and any other MCI’s | -- Generate a query/report of the dependencies between an MCI and any other MCI’s | ||
| - | - 10The MLMS shall provide a service to identify and alert on model inconsistencies, for example models synchronizations after an update to one of the Model Elements . | + | - The MLMS shall provide a service to identify and alert on model inconsistencies, for example models synchronizations after an update to one of the Model Elements . |
| - The MLMS shall provide services to enable 2 or more users to collaborate on the creation, review, update, and deletion of the same and different MCI’s within one or more models. This includes: | - The MLMS shall provide services to enable 2 or more users to collaborate on the creation, review, update, and deletion of the same and different MCI’s within one or more models. This includes: | ||
| -- Multiple users reviewing the same or different MCI’s at the same or different time | -- Multiple users reviewing the same or different MCI’s at the same or different time | ||
| Line 101: | Line 103: | ||
| ...and growing | ...and growing | ||
| + | |||
| Line 108: | Line 111: | ||
| * Integrate with PLM environment | * Integrate with PLM environment | ||
| * Manage SysML and its dependencies as a graph | * Manage SysML and its dependencies as a graph | ||
| - | * Unique id for all model elements | + | * Unique id for all model elements |
| - | * Model configuration item is the level the model is versioned | + | * Model configuration item (CI)is the level the model is versioned |
| - | * Model diff at element level | + | * Model diff hierarchical from CI to element level |
| * Model branch and merge capabilities | * Model branch and merge capabilities | ||
| * Capture incremental changes efficiently | * Capture incremental changes efficiently | ||
| Line 116: | 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 125: | 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}} | ||
| ===== Prototypes to demonstrate feasibility ===== | ===== Prototypes to demonstrate feasibility ===== | ||
| * JPL TBD | * JPL TBD | ||
| + | |||
| Line 135: | Line 150: | ||
| ===== SME/SysML v2 Service requirements (e.g. functions) to support model management ===== | ===== SME/SysML v2 Service requirements (e.g. functions) to support model management ===== | ||
| - | Below are a list of services key to MLM. However, most services listed in the {{00-SysML v2-Services-2015-11-26.xlsx| spreadsheet}} are useful for supporting MLM such as visualization and workflow. | + | Below are a list of services key to MLM. However, most services listed in the {{00-SysML v2-Services-2015-11-26.xlsx| spreadsheet}} are useful for supporting MLM such as visualization and workflow. Context specific services are listed in the Derived Requirements section above. |
| * Services to Manage Changes to the Model | * Services to Manage Changes to the Model | ||
| Line 171: | Line 186: | ||
| * Present MLM requirements in the context of change management scenarios | * Present MLM requirements in the context of change management scenarios | ||
| * Illustration of how concepts supports the Hybrid SuV scenario | * Illustration of how concepts supports the Hybrid SuV scenario | ||
| + | |||
| Line 177: | 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]> | |
| - | | TBD | TBD | <tbd@tbd.com> | | + | | Laura E Hart| MITRE | <lhart@mitre.org> | |
| - | | TBD | 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 |
sysml-roadmap/model_lifecycle_management_working_group.txt · Last modified: 2016-12-25 10:43 by sfriedenthal
Page Tools
