OMG SysML Portal

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Back to [[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group| SysML v2 RFP Working Group]]

====== MBSW Workflow and Collaboration Workgroup ======



===== Project Overview =====
The MBSE Workflow and Collaboration project will define the concepts, requirements, and metrics for an effective systems engineering workflow, its practices and collaboration that support the next generation system modeling language (SysML v2). 







===== Driving Requirements =====

  - The next-generation modeling language must be accompanied by a set of recommended, preferred processes
  - The next-generation practice repository must provide services for modifying, creating and implementing a preferred processes for model-based systems engineering  
  - Rather than only standardizing a modeling language and logical systems modeling environment (SME) process advice (based on industry norms) must also be provided
  - More streamlined and efficient model-based systems engineering processes will reduce the time and effort taken to build and maintain models and systems
  - Reduced learning curve when embarking on model-based systems engineering
  - Apply Software & Systems Process Engineering Metamodel™ specification (SPEM™) and BPMN




===== Example Use Cases =====

The Workflow and Practices systems engineers and other discipline engineers follow to develop and update the system model throughout the lifecycle to support system specification, design, analysis, and verification activities.  Plus their collaboration with other domains, such as Product Lifecycle Management (PLM)

tbd...



===== Status Quo =====
 
SysML v1.x provides no recommendations, norms or examples of MBSE implementation processes, collaboration best practices or workflows





===== Limitations of SysML =====

1.  Lack of reccomended best practices for applying MBSE, in the SysML Specifiction

3.  System model silos with limited standards for integration with adjoining specialisms

4.  Focus on language ignores tool environment concerns, such as collaboration 













===== Scope, High Level Ontology & Examples =====

{{sysml-roadmap:mbsewc1-v2.jpg|}}

1.  SE Lifecycle (when)
  Not formally part of the SME or the standard Practice Repository for SysML 2.0 and would be reccomended best practice lifecycle libraries;
      a. MBSE
      b. Systems of Systems
      c. System Product Line Engineering
      d. Rigor Aspects
      e. Agile Aspects

**__Design Review  - Example Practice 1__**

2.  PR Practice (Process Steps) (what)
      Design Review
3.  SME Workflow (SME Specific Process Steps) (what)
      View current design, identify improvements, propose changes, implement changes
4.  PR Techniques (how)
      Peer review, design review workshop, brainstorming, storyboarding
5.  SME Service (how)
      Automated design review, system model simulation, functional animation, m-2-m transformation (based on rules)
6.  PR Roles with Skills (who)
      System Design Reviewer with skills & competencies in MBSE
7.  SME User (who)
      The SME login for Bill Smith – who is a model-based systems engineer
8.  PR & SME  Tools (where)
      Systems modeling tool (generic, then site specific)
9.  PR & SME Deliverables (i.e. SME data subset, Work Product, Deliverable, Outputs, Input)
      This will typically be diagrams, groups of diagrams, viewpoints and states of all three
      Design review report, list of proposed improvements, improved model
10.  PR Values or Benefits provided (why)
      High quality system design, problems found early when cheaper to fix
11.  MBSE Risks & Mitigation
       Incomplete system design – mitigated by Design Review
12.  PR Metric (how much)
      Number of design problems found. Cost to fix design problems.
13.  Relationships between all of the above
      Risks for a Practice, Roles involved in a Practice, Deliverable from a Practice

**__Change in Requirement  - Example Practice 2__**

2.  PR Practice (Process Steps) (what)
      Change in Requirement
3.  SME Workflow (SME Specific Process Steps) (what)
      Elicit new/changed requirement, analyze the impact of the change, reject requirement, modify system design or compromise
4.  PR Techniques (how)
      Requirements change impact analysis, requirements coverage analysis
5.  SME Service (how)
      Trace link navigation, missing trace link report
6.  PR Roles with Skills (who)
      Requirements Engineer and Systems Engineer
7.  SME User (who)
      The SME login for Kirsty Walker – who is Requirements Engineer
8.  PR & SME  Tools (where)
      Requirements engineering tool and/or PLM tool (generic, then site specific)
9.  PR & SME Deliverables (i.e. SME data subset, Work Product, Deliverable, Outputs, Input)
      New requirements, updated model, change requests
10.  PR Values or Benefits provided (why)
      System meets stakeholders needs, agile response to changing needs
11.  MBSE Risks & Mitigation
      Requirements not met – mitigated by Requirements change practice
12.  PR Metric (how much)
      Number of Requirements.  Requirement complexity.
13.  Relationships between all of the above
      Risks for a Practice, Roles involved in a Practice, Deliverable from a Practice

===== Key Effectiveness Measures =====

1.  Clear and Understandable
       Measure: broad review (for clarity) inside and outside usual OMG/INCOSE audience
2.  Simple, Pragmatic and Relevant
       Measure: # of pages of documentation
3.  Modular and Applicable in Parts
       Measure: Can parts of the SEP be used autonomously (e.g. PLM Workflow)
4.  Generalist but Applicable to Specific Domains
       Measure: Reviews to eliminate domain specific language but also trials in different domains
5.  Scalable from Rigorous to Agile
       Measures: Trials
6.  Tool and Tool Vendor Agnostic
       Measures: Review for independence
7.  Aligned with Appropriate Industry Standards
       Measures: OMG Standards (SysML 2.0), OASIS Standards (OSLC, etc.)











===== SME/SysML v2 Service requirements (e.g. functions) for Workflow and Collaboration =====

Most services listed in the {{00-SysML v2-Services-2015-11-26.xlsx| spreadsheet}} are useful for supporting data traceability/interoperability.

1.  Create, Read, Update & Delete Practice Library, in the Practice Repository

2.  Export, Import and Merge Practice Library

3.  Distribute Updated Practice Library

4.  Create, Read, Update & Delete Practice, in the Practice Repository
    a. Relate Practice in the Practice Repository to a Workflow in the SME
    b. Relate Practice to a Practice in the Practice Repository as a Sucessor Practice
    c. Relate Practice to a Practice in the Practice Repository as a Parallel Practice
    d. Relate Practice to a Practice in the Practice Repository as a Child Practice
    e. Create, Read, Update & Delete Practice Decision, in the Practice Repository

5. Create, Read, Update & Delete Technique, in the Practice Repository
    a. Relate Technique in the Practice Repository to a Service in the SME
    b. Relate Technique to a Practice in the Practice Repository

6.  Create, Read, Update & Delete Role, in the Practice Repository
    a. Relate Role in the Practice Repository to a User in the SME
    b. Relate Role to a Practice in the Practice Repository

7.  Create, Read, Update & Delete Role Group (Team), in the Practice Repository
    a. Relate Role to a Role Group in the Practice Repository

    Notes; 
      Collaboration (in this context) is defined as 1) sharing common model data & 2) synchronizing tasks.
        1) Sharing data can be identified when more than one Role is involved (related to) a Practice (which has an Input, Working or Output Product (SME data sub-set).For example, on a project, this represents two engineers (possibly with different roles) creating, viewing, updating and deleting common SME data simultaneously.
        2) Synchronizing tasks are identified when one Practice (with an associated Role) initiates another Practice (which has a different Role associated).  For example, on a project, this represents one engineer completing a task, which then notifies another engineer that they can start their task. 
      The services for these will collaborations be needed in the SME Model Management concept.

8.  Create, Read, Update & Delete Generic Tool, in the Practice Repository
    a. Relate Generic Tool in the Practice Repository to a Specific Tool ot Tool Function inside the SME or outside the SME and interacting with the SME (via a standard API)
    b. Relate Generic Tool to a Practice in the Practice Repository

9.  Create, Read, Update & Delete Generic Deliverable (subset of SME data), in the Practice Repository
    a. Relate Generic Deliverable with a State to another State for that Generic Deliverable in the Practice Repository, as a sucessor
    b. Relate Generic Deliverable (and optionally its State) in the Practice Repository to a Specific Deliverable (subset of SME data and optionally its State) in the SME
    c. Relate Generic Deliverable to a Practice in the Practice Repository, as an Input
    d. Relate Generic Deliverable to a Practice in the Practice Repository, as an Output
    e. Relate Generic Deliverable to a Generic Tool in the Practice Repository
    f. Relate Generic Deliverable to a Role in the Practice Repository (note: this also defines data ownership and access rights)

10.  Create, Read, Update & Delete Benefit, in the Practice Repository
    a. Relate Benefit to a Practice in the Practice Repository

11.  Create, Read, Update & Delete Risk, in the Practice Repository
    a. Relate Risk to a Practice in the Practice Repository

12.  Create, Read, Update & Delete Metric, in the Practice Repository
    a. Relate Metric to a Practice in the Practice Repository
    b. Relate Metric to a Deliverable in the Practice Repository
    c. Relate Metric to a Benefit in the Practice Repository
    d. Relate Metric to a Riskin the Practice Repository

13.  Initiate Project, based on Practice (and its sub-Practices)

14.  Run Project based on Project specific Prcatice (and its sub-Practices)
    a. Visualize Practices with BPMN
    b. Record actual progress (Practices, Deliverables by Role & User)
    c. Capture Metrics
    d. Repot on progress and Metrics











===== Current Open Action Items =====

  - Align with SPEM and add terms to Glossary
  - HSUV Examples
  - Open question; should practice repository be part of the SME?
  - Add Requirements to master spreadsheet







===== Review Feedback and Action Taken =====

1.  Provide the capability to associate workflows with model construction (RW)
    Response; Generic capability to link Practices and Generic Tools with SME Tools and Tiool Features added to service list

2.  Metrics collection (SF)
    Response; Metrics collection added to service list

3.  Bundle the input data (CS)
    Response; Clarified that a Deliverable is purly an SME data subset and can also be used as an Input

4. Set up the Wiki for this concept (SF)
    Response; Wiki created



===== Review Material =====
  *{{ :sysml-roadmap:workflow_and_collaboration_concept_and_proposed_requirements-draft_v3_.pptx |SysML v2 Workflow and Collaboration Concept and Proposed Requirements-draft v3 Dec 08, 2016)}}
===== Team =====
^ Name ^ Organization ^ email ^
| Hedley Apperly | [[http://www.ptc.com/| PTC]] | <happerly@ptc.com> |
| Ron Williamson | [[http://raytheon.com/| Raytheon]] | <ron_c_williamson@raytheon.com> |

Others tbd on request


Last updated April 11, 2016
OMG SysML Portal

User Tools

Site Tools

Page Tools
