This is an old revision of the document!
MBSE Usability
Purpose
ISO defines usability as “The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.“
Our purpose is to identify how systems engineering languages such as SysML, processes, and supporting tools can be made easier to learn and use and to promote usability improvements.
Our definition of the Model Based Systems Engineering (MBSE) Environment is that it consists of:
The Language in which people express models, (for now, predominantly SysML)
The Tools that people use to build and manipulate models
The Methods - that people follow to build models
Synthesis - Transcends single category
Measure of Success
Identify usability levels to focus discussions.
Identify method to communicate usability issues (such as metrics or pain points or usability matrix).
Conduct a root cause analysis for each usability issues to identify suggestions to standards groups or tool vendors.
Schedule
Date | Milestone | Status | Point of Contact |
Jan 2011 | Develop Usability Use Cases | Ongoing | David Lempia |
Nov 2012 | Complete Library Exemplar Document Published | Submitted for INCOSE 2013 IS | Scott Workinger |
Feb 2013 | Condense Library Exemplar Paper to 15 pages | Ron Lyles & David Lempia | |
June 2013 | Library Best Practices | Working Group Sessions at IS | Bjorn Cole |
Dec 2013 | Complete Library Best Practices | Ready for IW | Bjorn Cole |
Team Members
Materials
Emerging Usability Patterns in the application of modeling libraries, Published Feb 2013
Usability Use Cases collected January 31, 2011
The usability dimensions describe key aspects of usability that are measurable during experiments. The four usability dimensions are:
The scope of the usability groups work includes:
Use cases will be collected that describe how a systems engineer creates engineering artifacts for a specific customer during a specific systems engineering process step. The type of information we will collect for use cases include:
Goal - What is the goal of the use case? (Focus on the produced engineering artifacts and the needs of the customer)
Actors – Who are the actors involved in this use case? Who is the customer?
Usability Hypothesis – What are the expected usability issues that may be encountered in this use case?
What systems engineering process is supported?
Pre-condition – What is the state of the tools and engineering artifacts before the use case begins. What are the inputs needed to start this use case.
Post-condition – What is the state of the tools and engineering artifacts after the use case finishes. What are the outputs from this use case.
Sequence of tasks - What are the tool independent tasks the primary actor does (Starts with a verb) (What SysML element(s) and/or diagram(s) is used?)
MBSE Value Added - What is the value added to this use case because I used MBSE as opposed to traditional methods?
Assemble components and associated behaviors from a library of primitives to meet the mission need
Actors - Architect, systems engineers/component designers, librarian, interface designer, Change Control Board
Process - Collaboration, Analysis & simulation, Configuration Management Tools
Pre-condition - Mission needs understood, Library of components, each meeting criteria for reuse
Post condition - Architect and collection of components, meeting the proposed mission need
Sequence of tasks
SE searches repository for components, based on criteria/desired function
SE selects and connects component abstractions in system model
SE/integrator initiates performance analysis, simulation to verify behavior
SE reconfigures components as necessary
Goal - Conduct a Design Review using MBSD Environment
Actors - SE, Architect/Designer, Customer, PM, Eng Mgmt, Peers
Process - Collect changed artifacts and supporting artifacts into a form that can be commonly sharable, i.e. document or html form. Highlight all changed items.
Pre-condition - Change Complete, Completed design review checklist
Post condition - All issues adjudicated, Ready for re-baseline
Sequence of tasks
Identify modeling artifacts and external artifacts that have changed or support the change
Create review artifact that is sharable across all reviewers. Artifact should highlight all changed items, both textual changes, changes to a diagrams/tables and any model element properties, including logical/physical elements, requirements, relationships, etc.
Distribute review artifact and initiate review process
Collect issues, resolve and capture resolution
Review adjudication with reviewers
Merge changes and re-baseline
Goal - Make assertions on current design
Actors - Accountable engineer makes assertions, reviewers evaluate
Process - Cross-cutting – focused on constraints
Pre-condition - Assertions are made, simulations and analysis run
Post condition - Reviews have concurred or not concurred that assertions are properly validated/tested
Sequence of tasks -
Goal - Define system architecture and conduct architectural analysis
Actors - Systems engineer performing architecting function
Process - Many candidate methodologies for sys arch, UML/SysML diagram tips: Pkg diagrams, BDDs, Class diagrams
Pre-condition - Architectural approach/methodology adopted, Modeling languages and tool(s) selected, Profiles exist and have been imported
Post condition - System architecture (logical/conceptual) captured in system model and validated
Sequence of tasks -
Specify architectural properties and constraints/drivers
Consider arch alternatives
Describe architecture (use views/view points)
Refine requirements and design
Develop scenarios===== Reference Links =====
Documents and Presentations
2011 International Symposium
2011 International Workshop
Use Case Analysis
MBSE Usability Collaboration Issues & Path Forward - May, 2011
Usability Reference Materials
Candidate Usability Use Cases
Usability Exemplars from Industry
INCOSE Links
OMG Links
External Links
Cross Team Links