INCOSE IS 2013 Usability Group Session #1 June 25, 2013

Slides:



Advertisements
Similar presentations
Integration of MBSE and Virtual Engineering for Detailed Design
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Visual Scripting of XML
Architecture Representation
July 11 th, 2005 Software Engineering with Reusable Components RiSE’s Seminars Sametinger’s book :: Chapters 16, 17 and 18 Fred Durão.
Midterm Exam Review IS 485, Professor Matt Thatcher.
UML CASE Tool. ABSTRACT Domain analysis enables identifying families of applications and capturing their terminology in order to assist and guide system.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Architectural Design Principles. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Chapter 7 design rules.
Course Instructor: Aisha Azeem
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Domain-Specific Software Engineering Alex Adamec.
CASE Tools And Their Effect On Software Quality Peter Geddis – pxg07u.
IBM Proof of Technology Discovering the Value of SOA with WebSphere Process Integration © 2005 IBM Corporation SOA on your terms and our expertise WebSphere.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
An Introduction to Software Architecture
High Level Architecture Overview and Rules Thanks to: Dr. Judith Dahmann, and others from: Defense Modeling and Simulation Office phone: (703)
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
CHAPTER TEN AUTHORING.
Design engineering Vilnius The goal of design engineering is to produce a model that exhibits: firmness – a program should not have bugs that inhibit.
Design Rules-Part B Standards and Guidelines
SE: CHAPTER 7 Writing The Program
Lecture 7: Requirements Engineering
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Chapter 6 – Architectural Design Lecture 1 1Chapter 6 Architectural design.
Software Reuse Course: # The Johns-Hopkins University Montgomery County Campus Fall 2000 Session 4 Lecture # 3 - September 28, 2004.
February 19, February 19, 2016February 19, 2016February 19, 2016 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific.
Emerging Usage Patterns in MBSE Modeling Libraries MBSE - Usability Group January 26, 2013 SoS Modeling Framework at Honeywell Domain-Specific Customization.
MBSE – Usability Working Group IS2011 Supporting the Emergence of Usability in the Community of practice.
Model Based Engineering Environment Christopher Delp NASA/Caltech Jet Propulsion Laboratory.
Design Engineering 1. Analysis  Design 2 Characteristics of good design 3 The design must implement all of the explicit requirements contained in the.
Design rules.
Interface Concepts Modeling Core Team
MBSE Usability Group Bjorn Cole
CompSci 280 S Introduction to Software Development
INCOSE Usability Working Group
INCOSE Usability Working Group
Object-Oriented Analysis and Design
Introduction to Design Patterns
Modern Systems Analysis and Design Third Edition
Unified Modeling Language
SysML v2 Usability Working Session
Software Processes (a)
Software Quality Engineering
Software Processes.
Model-Driven Analysis Frameworks for Embedded Systems
Object-Oriented Analysis
Tools of Software Development
Ch 15 –part 3 -design evaluation
HCI – DESIGN RATIONALE 20 November 2018.
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Chapter 20 Object-Oriented Analysis and Design
Usability Techniques Lecture 13.
Object oriented analysis and design
Analysis models and design models
An Introduction to Software Architecture
INCOSE IS 2013 MBSE Plenary June 24, 2013
Automated Analysis and Code Generation for Domain-Specific Models
Presented By: Darlene Banta
Chapter 7 design rules.
敦群數位科技有限公司(vanGene Digital Inc.) 游家德(Jade Yu.)
Chapter 7 design rules.
Chapter 7 design rules.
Quick orientation for MBSE Usability Group
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Chapter 7 design rules.
From Use Cases to Implementation
Presentation transcript:

INCOSE IS 2013 Usability Group Session #1 June 25, 2013 MBSE Usability David Lempia

Introductions Name Company Experience with Modeling Systems

Agenda What is usability? What exemplars did we capture? What libraries would you like? Literature review Paper Outline for Library Guideline & Usability Challenges Authors???

From INCOSE IW 2011 Top 4 Hi-value use cases: Assemble components and associated behaviors from a library of primitives to meet the mission need Conduct a Design Review using MBSD Environment Make assertions on current design Define system architecture and conduct architectural analysis

What is Usability? A key part of human-machine interface According to Usability.gov: measures the quality of a user's experience when interacting with a product or system whether a Web site, a software application, mobile technology, or any user-operated device … combination of factors, including: Ease of Learning Efficiency of Use Memorability Error Frequency / Severity Satisfaction

What is Usability? (2) According to SEI, a usable program: Increases individual user effectiveness Expedites routine performance Accelerates error-free portion of routine Reduces impact of routine errors Improves non-routine performance Supports problem-solving Facilitates Learning Reduces impact of errors caused by lack of knowledge Prevents mistakes Accommodates mistakes Reduces impact of system errors Increases user confidence and comfort

Quantifying Usability (Web) Some methods elicit typical user mental models: Card sorting – what categories to users naturally group ideas into? Contextual interviews – how do your users typically attempt to solve problems? Focus groups – what is common about your users and what is divergent? Personas – what do you think about when describing your users?

Quantifying Usability (Web) Tests reveal challenges: Have users attempt to utilize the functionality of the software Track time to complete, mistakes, and subjective experience of the user

Key Heuristics (Nielsen + Shneiderman) Strive for consistency (a big one for the language!) Reduce short-term memory load Recognition rather than recall Help users recognize, diagnose, and recover from errors Keep system status visible Enable frequent users to use shortcuts Design dialogs to yield closure Match between system and real world Permit easy reversal of actions Language Tool

Paper 1 Abstract. This paper summarizes the conclusions of the MBSE Usability Group for 2012. Five perspectives are offered with each perspective grounded by an exemplar from the authors’ practice using Model Based Systems Engineering Environments. These exemplars range from very detailed step-by-step descriptions with identification of fine-grained usability issues to system of systems simulations developed by geographically dispersed operations in a global company. Discussion of each exemplar within the Usability Group led to significant lessons learned for the team. This paper summarized the chief lessons learned during this process. Today, the process continues. In the words of Ron Lyells, “Usability is an emergent quality.”

Paper 1 David Lempia - Identified basic library use cases 12 Usability Challenges Ex: It is hard to find, identify, and understand the usage of library elements in a model. Bjorn Cole – Specialized Domains Judy Che - Architecture George Sawyer – Library Templates Craig Schimmel & Ron Lyells – Architecture

Scope: You Will Find Yourself Designing An Agile Complex SoS Components: Simulation Sets, Simulation Tools A/C Pwr A/C ECS) Integrity Management Environment ATC A/C FMS Sim Control COTS Tools Data Capture Measures Infrastructure evolution: System assembly: Component mix: Component inventory: Industry Assoc Simulation Integrators Simulation Modelers Engineering Functions Active Infrastructure Role separation: simulation developer vs simulation integrator Architecture goals: Simulation environment: Borrowing from agile systems, and service oriented architectures: System comprised of reusable simulation modules, and framework rules (defined but less rigid coupling) hide simulation interface details from user Library management defined, assigned Persistent environment: Over time modules are added, maybe updated, different simulation systems of systems can be formed and utilized. Infrastructure defined but allowed to evolve as technology and techniques advance. SIM Scenarios are essentially plug and play systems of simulations. The scenarios can be expanded as needed, or simplified as needed. Passive SIM Scenario 1 SIM Scenario 2 SIM Scenario 3 Rules Object Model Templates Application Protocols Interface Specifications Standards: DIS IEEE 1278.1, HLA IEEE 1516.1 SIM API roughly… ‘90s ‘2000s ‘10s

What Do Non-Executable Libraries Offer? “Best in Class Algorithms” What does this mean in SysML? Rather than high-performance algorithms, models that are well-formed to support high-performance algorithms as data objects Aids to making descriptive models descriptive For users - where are the semantic zoom points? E.g., in propulsion: tanks at thrusters at all levels, maybe valves not until one or two levels of depth How should the model elements lead the user? In viewing? In updating? In composing? The key to descriptive models is that they capture and can regenerate new presentations of the implicit interconnections between multiple descriptions. This makes them powerful for working with federated analyses. Like any data source for computer algorithms, descriptive models can be constructed to either aid or obstruct computational efficiencies. In SysML, models can be built where it is easy to find related properties (via containment relationships) or can require a full traversal of the model (following non-navigable associations “backward” to find all types that have a part of the type that starts the query). High-quality libraries should respect these computational needs. For semantic zooming, a user could automatically “zoom out” (reduce detail to get an overview of what the model view is showing) or “zoom in” (add detail). To do this well, the semantics of what is “high level” versus “low level” need to be encoded. In the case of a propulsion system design, the number and overall branching approach to thrusters is important at the top level but not necessarily the implementation of the various valves. A base model can lead to generating views, be updated, or be composed (along with other atomic functions). A top-class library should be able to guide the user in performing each of these atomic functions.

Example – Customizing MagicDraw to express library in domain view

Vehicle Model Architecture High-level modular structure for dynamic vehicle modeling Key vehicle subsystems are represented as distinct elements Subsystem connections specified through well-defined interfaces Signals distributed to subsystems via defined bus structure Structure & interface are fixed, model content is not Simulink implementation of the Vehicle Model Architecture or VMA. At a high level the VMA is a modular structure created for dynamic modeling of vehicle systems The vehicle itself is broken down into a number of key subsystems which are represented as distinct elements The connections between these subsystems are specified through a set of well-defined interface signals The VMA itself is simply modeling framework where the structure and interfaces of the model are defined, but the actual model content is left up to the user. This framework can be populated with component models of varying degrees of fidelity from a variety of sources depending the particular modeling objectives. And as long as the interfaces comply with the VMA Standard, the model can have 'plug-n- play' compatibility. Creating models that fit the common structure makes it easier to share and re-use models These are the key features of the VMA that make it suitable for integrated control development.

Use Case Build domain models – Plant and Controls for each subsystem Create re-usable libraries of component models with varying levels of fidelity Integrate appropriate components to build up vehicle system model based on a vehicle model architecture – based on desired analysis Use Variant Management to configure model selection and auto-wire models together Transmission Engine Driveline Electrical Chassis Plnt Ctrl Lo Med High 8-Nov-18 17 17

Possible Starting Points for Creating a New or Adapted SysML System Model Blank model No support beyond the tool capabilities Relies entirely on model expertise Problem example models Good for explaining model concepts Often not the best choice for a large, complex model development Generic system model template Can provide a generalized model usable in many different domains Can provide significant infrastructure Domain-specific module template Advantages of the generic template plus additional domain infrastructure

Inclusion of “Pro-Forma” Examples for Correct Usage of Model Elements and Diagrams

Takeaways from IW 2013

Recommendations: The User Experience Understand libraries as a crucial corporate asset. Make exemplars of correct usage available in templates to streamline training and work (Put the best at people’s fingertips.) Best Practices / Process examples Example models Generic Domain-Specific Best of class algorithms Design the user experience. Understand your users. (Most users will not be modeling geeks!) Keep it simple Support flow Make it “write once” for the modeler Create an immersive environment for users As if it was a multi-player game (Because it is!)

Recommendations: Power Tools For trade studies: Support Model Variants Support Parameter Sets Representational Power Support Rich Objects Support Architecture & Design Patterns Create an end user programming environment Enhance modeling efficiency by supporting macros. Bring power to programs with abstract binding capabilities. Allow objects to tailor themselves when placed. Make it as easy to use as a spreadsheet

Recommendations: Implement Service Oriented Architecture Vehicle Model Architecture at Ford Motor Company REAL Runtime Architecture at Honeywell Similarities suggest using a SOA Architecture Separate the interface code from model code Different roles for engineers who model vs. integrate environment Different locations in library for models vs. integration code Develop Standard Interface Protocols Support: Collaboration Plug & Play, Sharing, Re-use Mashups

Recommendations: Supporting Collaboration Immersive Multi-Modeler Environment Shared awareness Supporting spiral of meaning Dialog about applying modeling during projects Dialog about library objects New insights into library components Emerging architectural & design patterns Dialog happens inside the modeling environment

INCOSE IS 2013 Usability Group Session #2 June 26, 2013 MBSE Usability David Lempia

Introductions Name Company Experience with Modeling Systems

Brainstorm Identify a set of desired re-usable library objects If you could start your systems model with any library building blocks, what would you want? Write 3-5 ideas down on a sheet of paper In turn, share 1 new idea with the group or pass

Session 2 Wednesday Review Literature (Reusable Asset Specification) Create Library Guide Paper Outline Identify Interested Authors – Assign a section of the paper

Papers Reusable Asset Specification, OMG Available Specification, Version 2.2, Nov 2005 Evolution and Composition of Reusable Assets in Product-Line Architectures: A Case Study, Jan Bosch Metamodeling for Requirements Reuse, Oscar Lopez Building Reusable Testing Assets for a Product Line, John D. McGregor A Model for Effective Asset Re-use in Software Projects, Abhay Joshi

RAS

A model for effective Asset Re-use in Software Projects

Paper Outline 1.0 Introduction 2.0 What is a system library? 2.1 Meta Data Needed to Support Libraries Solution Interface (Limit external relationships to these elements) Variants (Items that can change during usage) Include another library element Change a path Change a variable Common (Items that can not change during usage) Dependencies to other library elements

Paper Outline 2.2 Meta Data Needed to Support Libraries (Continued) Dependencies to other library elements Classification of library element Usage (How/Where can I use this library?) Change History 2.3 Industry Needs (example desired libraries)

Paper Outline 3.0 Best Practices for Creating, Sharing and Using Libraries Have a Suggestive Interface Exploit Metaphors Make Dependencies Explicit Build in Variation Apply Configuration Control Provide Affordances 4.0 Usability Challenges 5.0 Conclusion

Systems Libraries to Share Filters (lo-pass, hi-pass), Logic (and, or) Computer resources (Intel Core 2 with 2 GB RAM) Interface (ARINC 429, MS 1553) Drag & Drop Pre-configure Subsystems, Environments filtered and sorted by abstraction Catalog / pre-configured objects that can be composed into missions or scenarios Rapid way of sketching objects, then refining until pre-defined elements can be placed into the sketch; transition from sketch to model.

Systems Libraries to Share Basic hierarchy with structure and behaviors All functions associated with SE life cycle Creational patterns A palette of objects with Visio-like graphic icons A framework or template or wizard to guide the process A library catalog – an index that is searchable and browsable Architecture patterns and templates Gang of 4 patterns

Systems Libraries to Share Complete standard unit library Constraint blocks for converting the same parameters to different forms Variable abstraction level for components Versions and variants; parametric models or built-in variability (CVL?) Multi-view point domains

Task - How might this work? Teams of 2-3 Pick an example from the list or select a new example Try to capture all of the information for a reuse library element. What would it look like? What SysML elements would you use? Draw pictures, create tables, document usage. Example, Lo-Pass Filter Solution Interface – Signal in, Signal out, Reset Variant – Time Constant Include another library element - None Change a path - None Change a variable – Time Constant Common Activity Diagram Etc.

Task – Paper Outline Who is interested in working on the paper? Are you interested in a specific section?

Thank You for your Help