Model-Based System Integration (MBSI) An Instructional Approach Dr. Paul Montgomery Associate Professor of Systems Engineering Naval Postgraduate School.

Slides:



Advertisements
Similar presentations
Systems Engineering From a Life Cycle Perspective John Groenenboom Director Engineering – Mesa Boeing Rotorcraft Dec 12, 2007.
Advertisements

Instructional Decision Making
Testing Workflow Purpose
1 INCOSE Chesapeake Chapter Enterprise SE Panel Discussion L. Mark Walker/LMC 21 March 2007.
Prescriptive Process models
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CS487 Software Engineering Omar Aldawud
Chapter 4 Quality Assurance in Context
Systems Engineering in a System of Systems Context
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Software Testing and Quality Assurance
Copyright © 2006 Software Quality Research Laboratory DANSE Software Quality Assurance Tom Swain Software Quality Research Laboratory University of Tennessee.
SE 555 Software Requirements & Specification Beyond Requirements Based on Weigers Chapter17.
System-of-Systems Cost Modeling: COSOSIMO July 2005 Workshop Results Jo Ann Lane University of Southern California Center for Software Engineering.
Chapter 2 - Overview of the Systems Engineering Design Process1 Aerospace Systems Engineering Chapter 2 - Overview of the Systems Engineering Design Process.
Software Testing & Strategies
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Software System Integration
What is Software Architecture?
Effective Methods for Software and Systems Integration
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
Dr. Ken Hoganson, © August 2014 Programming in R STAT8030 Programming in R COURSE NOTES 1: Hoganson Programming Languages.
CPTE 209 Software Engineering Summary and Review.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
CMSC 345 Fall 2000 Unit Testing. The testing process.
Rational Unified Process Fundamentals Module 4: Disciplines II.
The Challenge of IT-Business Alignment
Logistics and supply chain strategy planning
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
1 Systems Engineering Process Review Mark E. Sampson EMIS 8340 Systems Engineering Tool—applying tools to engineering systems.
Engineering System Design
Best Systems Engineering Products Drive CMMI NDIA 6th Annual Systems Engineering Supportability & Interoperability Conference October 21, 2003 Dr. Tom.
Testing Basics of Testing Presented by: Vijay.C.G – Glister Tech.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
Testing Workflow In the Unified Process and Agile/Scrum processes.
OOI CI LCA REVIEW August 2010 Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger Life Cycle Architecture Review.
Space Systems Engineering: Functional Analysis Module Functional Analysis Module Space Systems Engineering, version 1.0.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Software Engineering - Abdul Majeed. What is software? Definition of Software Engineering Software Process Generic view of Software Engineering Software.
Chapter 8 Lecture 1 Software Testing. Program testing Testing is intended to show that a program does what it is intended to do and to discover program.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CSPC 464 Fall 2014 Son Nguyen. 1. The Process of Software Architecting, Peter Eeles, Peter Cripss 2. Software Architecture for Developers, Simon Brown.
Overview of SAIP and LSSA. Software Architecture in Practice Provides a set of techniques, not a prescriptive method for architectural design. Based on.
Smart Home Technologies
Leadership in Groups and Teams Chapter 7. “When building a team, I always search first for people who love to win. If I can’t find any of those, I look.
Effective SE Communication through Models and Representations David Long INCOSE Copyright © 2015 by D. Long. Published.
Software Engineering Lecture 10: System Engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
What IS RtI?. National RtI Model “Response to Intervention” –Born out of Reauthorization of Special Ed Law (IDEA 2004) Two Models of RtI: –Problem-Solving.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
Project Management Enabling Quality Marien de Wilde, PMP April 2007.
INCOSE IW12 MBSE Workshop 15 INCOSE (MBSE) Model Based System Engineering Integration and Verification Scenario Ron Williamson, PhD Raytheon
International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA INCOSE IW 2012 MBSE Requirement Flowdown Workshop - Outbrief - John C. Watson Principal Member.
Project Office Effectiveness Educating the Organization on How to Use a PMO February 22 nd, 2006.
The Software Lifecycle Stuart Faulk. Definition Software Life Cycle: evolution of a software development effort from concept to retirement Life Cycle.
IEEE Std 1074: Standard for Software Lifecycle
Software testing strategies 2
Software System Integration
By Jeff Burklo, Director
Model-Based System Integration (MBSI) An Instructional Approach
Software System Integration
Presentation transcript:

Model-Based System Integration (MBSI) An Instructional Approach Dr. Paul Montgomery Associate Professor of Systems Engineering Naval Postgraduate School May 15,

Perspectives Calibration  Developmental SE  SI – Different perspective from SEs  DoD – Developing complex systems  Academia – SE professor  MBSE – Evolving and maturing  MBSI – An idea (MBSE from SI’s perspective) 2

BLUF  Integration Integration begins at design  Modeling Don’t try to integrate the system until you successfully integrate the system model  Instruction Integration must be experienced, not merely studied 3

Essential Concepts of I&Q 1  Integration = ensuring the system comes together Interfaces (connectivity and flow)Interfaces (connectivity and flow) Interactions (also interoperability)Interactions (also interoperability)  Qualification = ensuring the system is acceptable to the customer (aka ‘acceptance’) Building the system correctly (aka ‘verification’)Building the system correctly (aka ‘verification’) Building the correct system (aka ‘validation’)Building the correct system (aka ‘validation’) 1 I&Q = Integration and Qualification 4

What’s the Problem?  Many system developments fail at integration & qualification (I&Q) … and fail badly  Added cost, schedule, and needed redesign 1 Hershey Foods Corp. PROJECT: IBM-led installation and integration of SAP, Manugistics Group Inc. and Siebel Systems Inc. software…Hershey sales fell 12% in the quarter after the system went live — down $150.5 million compared with the year before Norfolk Southern Corp. PROJECT: Systems integration with merger target Consolidated Rail Corp…Norfolk Southern lost more than $113 million in business during its 1998/1999 railroad merger with Conrail. Custom logistics software wasn’t tested properly and a dispatcher mistakenly fed bogus test data into the system Tri Valley Growers PROJECT: Oracle Corp. ERP and application integration…Tri Valley bought at least $6 million worth of ERP software and services from Oracle in None of the software worked as promised; some of it couldn’t even be installed on Tri Valley’s DEC Alpha hardware, the co-op claimed in a $20 million lawsuit filed in February. From: “Top 10 Corporate Information Technology Failures” 5

Where are we (DoD) Going? - DoD and SoS/LSI (Gansler)  SoS acquisition and engineering is the norm in DoD  SoS design, integration and qualification (I&Q) is highly complex  DoD engineering workforce not well aligned to LSI responsibilities 6 Government oversight of LSI has been complicated with contractual ambiguities Delineation of “inherently governmental functions” for LSI needs more clarity Private LSIs have inherent conflicts of interests without specific controls SoS integration requires a strong, centralized LSI

If SE is Well Defined, Why is I&Q a Challenge?  What’s wrong with this picture? 7

INTEGRATION BEGINS AT DESIGN MBSI 8

What is a System Model? 9 CORE Model Functional Decomposition (Hierarchy) Functional Flow Model (FFBD) Interface Diagram (N 2 ) Generic Physical Block Diagram Behavior Diagram (Sequence) Functional Process Model (IDEF0)

MBSI – The SI’s MBSE Perspective Design Environment Qualification Environment Modeling Environment Integration Environment MBSE? MBSI ? 10

SE Activities Should Produce System Definition/Model Functional Model Operational Model Interface Model Physical Model Behavioral Model System Definition (“Model”) 11

System Model Underpins I&Q Activities 12

Don’t try to integrate the system until you integrate the model System Modeling 13

Progressive Integration 14 Different teams in diverse locations

Integration and Qualification Considerations from Functional Analysis 15 Complex flows/connectivity may indicate complex interactions and bears special attention for integration and qualification focus (or possible redesign)

Integration and Qualification Considerations from Behavior Analysis 16 High behavioral interaction activity bears special attention for integration and qualification focus (or possible redesign)

Integration and Qualification Considerations from N 2 Analysis 17 Function 1 Function 2 Function 4 Function 5 Large number of interface content (complex interactions) can warrant special integration and qualification focus (or possible redesign) Function 3

INTEGRATION MUST BE EXPERIENCED, NOT MERELY TAUGHT I&Q Instructional Methods 18

System Model System model is essential for project success Popular Approaches to Teaching I&Q SE Fundamentals SE Integration Test and Eval Concept Design Build Integrate Qualify Process Approach “Toys” Approach End-to-End Approach Shortfalls: Non-tangible experience Hard to develop I&Q instincts Disjointed learning experience Shortfalls: Cannot design components Interfaces are fixed Interface design may be hidden Shortfalls: Not enough time Not enough student skills Set up for failure 19

A PROJECT MBSI Instructional Example 20

Overview of Class Project SOH Submarine Detection using Fire Scout (STRAIT SCOUT) 21

Customer Problem Statement Problem In the Persian Gulf, we do not have a reliable system to detect submarines that egress and ingress through the SOH by hiding in tanker wakes. Research Questions Can a combination of BAMS and one FireScout be used to provide a high P d of the submarine behavior above? What is shipping traffic density vs. P d performance of such a system? What are some FireScout search strategies for such a system deployment? 22

Primary System Assets  BAMS - Persistent surveillance over AOR with surface search Radar  Fire Scout Speed = 0 – 90kts  FireScout Sensor = LIDAR (Light Detection and Ranging) Scanning Sub – inch resolution 23

Top-Level STRAIT SCOUT Architecture Concept 24 SensorSensor Red Team FireScoutFireScout C2C2 Test Parameters (Parameters, Scenarios, Results) – Ships and sub position data 2 – N/A 3 – Surface track data 4 – Sensor data 5 – Flight path commands 6 - Position data 7 – Environment parameters 8 – Test results BAMSBAMS

Team Roles & Responsibilities  LSI Primary stakeholder negotiations Top-level architecture Taxonomy and structure – External systems interfaces – Intra-subsystem interfaces – Functional naming conventions Conop Integration and qualification strategy – Integration strategy – Acceptance goals, objectives, and agreements Leadership  Subsystem teams Subsystem derived requirements Subsystem Design – Functional, interfaces, and generic physical Subsystem integration and qualification  Instructor = Primary customer/stakeholder 25

SE Design  Define the problem  Develop functional architecture  Develop physical architecture  Develop operational architecture  Develop interface architecture  Define integration, test, V&V strategy 26

Simulation Concept 27 time = t time = t n FireScout sensor scan field Tanker track and direction time Detection? Wake (no sub) Wake (with sub)

VBA Project I&Q Environment Excel ™ VBA Excel ™ VBA Excel ™ VBA “Dictator” VBA “Dictator” Excel ™ Subsystem A Subsystem B Subsystem C System LSI Team Subsystem Teams Advantages: Readily available “Office” tools Concept-to-design Interface visibility Team integration = subsystem integration LSI integration = system integration Disadvantages: VBA is not innate SE skill Too much to do in time alloted Integration can still be undisciplined 28

MBSI Environment Implementation Physical Modeling Behavioral Modeling Interface Modeling Qualification Modeling Conop Needs Mission Constraints Assumptions Goals Objectives Cell formulas and VBASheets and cells modeling Functional Modeling “Design” “I&Q” 29

Primary Class Project Phases  System design  Model integration (CORE 1 )  System development (code)  Subsystem & System integration  System verification (test)  System validation (demonstrate)  System acceptance (grade) 1 CORE 8 (University) Service pack 3 30

THE SI PERSPECTIVE MBSI Instructional Example 31

SI Challenge Questions  Do you understand your problem and what your subsystem needs to do?  Do you understand enough about your subsystem behaviors to define functions?  How many functions are in your subsystem?  Are the functions “modular” and simple?  How many interactions do you expect?  How many external interfaces do you need to define?  How many internal interfaces do you need to define?  Have you thought of which functions need to be integrated first?  What are the integration and qualification risks that are starting to emerge? 32

Simplified Strait Scout Sequence Diagram? 33 C2 FS LSI Red Sensor Setup / Run Sub detected Record Terminate Locations Flight Cmds Fly/ Location loop BAMS Target Data

Strait Scout Functional Context Systems 34 Control flow is linear?

N2 35 Interface complexity?

IDEF 36 Many interfaces?

Sequence 37 Triggers? Responses?

Student Discoveries  Early requirements clarification is important  Early architecture design imperative (especially functional and interface)  Rushing to development prior to model definition wastes time and effort  Early model integration drives out:  Functional gaps and overlaps  Interface inconsistencies and discontinuities  System behavior misunderstandings  Inter and intra-system interface problems  SI involvement in design can reduce risk during I&Q  Project would have failed without MBSE/MBSI methods 38

LESSONS LEARNED MBSI – An Instructional Approach 39

Value of MBSI  Successful I&Q requires: Strong LSI / SI Detailed system definition (particularly interfaces and functional interactions) Early taxonomy and structure definition Early SI influence with I&Q success perspective Modeling in order to discipline design efforts Model integration prior to system integration to reduce I&Q risks Diverse and integrated SE/SI support system (i.e. tool sets, etc.)  MBSE tools not yet MBSI tools  “Teach” I&Q using MBSI applied to experiential project 40

References  Handbook of Systems Engineering and Management, Sage and Rouse (ed.), Wiley and Sons, 1999, Chapter 14  Systems Engineering Guide for Systems of Systems, Ver 1.0, Aug 2008, Director, Systems and Software Engineering, DUSD (Acq and Tech), OSD (AT&L)  The Role of the Lead System Integrator, Gansler, et.al., NPS-AM , Jan 2009  Top 10 Corporate Information Technology Failures, pdf pdf  content/uploads/2012/04/customer-experience-focus.jpg content/uploads/2012/04/customer-experience-focus.jpg    WfiI8DI/AAAAAAAAD88/tzcvl7wxgRA/s1600/acellphone.gif WfiI8DI/AAAAAAAAD88/tzcvl7wxgRA/s1600/acellphone.gif 41