Systems Engineering in a System of Systems Context

Slides:



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

Systems Engineering for Systems of Systems
Introduction to Product Family Engineering. 11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering.
State of Indiana Business One Stop (BOS) Program Roadmap Updated June 6, 2013 RFI ATTACHMENT D.
© 2009 The MITRE Corporation. All rights Reserved. Evolutionary Strategies for the Development of a SOA-Enabled USMC Enterprise Mohamed Hussein, Ph.D.
ERS Overview 5/15/12 | Page-1 Distribution Statement A – Cleared for public release by OSR, SR Case #s 12-S-0258, 0817, 1003, and 1854 apply. Affordable,
Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University 1 Pittsburgh, PA Dennis Smith, David Carney and Ed Morris DEAS.
Evoking a Core SE Technical Development Methodology to Develop a SyS, FoS, and SoS Darryl A. Gomez, PhD May 16, 2012.
University of Southern California Center for Systems and Software Engineering SoS Engineering and the ICM Workshop Overview Jo Ann Lane USC CSSE
Software Engineering Techniques for the Development of System of Systems Seminar of “Component Base Software Engineering” course By : Marzieh Khalouzadeh.
Recent DoD Trends & System and Software Process Implications
1 Incremental Commitment Model as Applied to DoD Acquisition Insights from a Business Process Model of DoD Acquisition Policy and SE Guidance Dr. Judith.
Process Synchronization Workshop Summary Report Jo Ann Lane University of Southern California Center for Software Engineering.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
1/31 CS 426 Senior Projects Chapter 1: What is UML? Chapter 2: What is UP? [Arlow and Neustadt, 2005] January 22, 2009.
Iterative development and The Unified process
S&I Data Provenance Initiative Presentation to the HITSC on Data Provenance September 10, 2014.
Program Analysis & Evaluation 1 © 2006 July 13, /18/98 2:13 PM Research Sponsors Robert Flowe, Gary Bliss OSD Program Analysis and Evaluation, Resource.
1 CS 426 Senior Projects Chapter 1: What is UML? Chapter 2: What is UP? [Arlow and Neustadt, 2002] January 26, 2006.
Advancing Government through Collaboration, Education and Action Financial Innovation and Transformation Shared Services Workshop March 17, 2015.
Using SysML to Estimate SoS Engineering and Development Effort Jo Ann Lane Tim Bohn COCOMO.
What is UML? What is UP? [Arlow and Neustadt, 2005] January 23, 2014
UML - Development Process 1 Software Development Process Using UML (2)
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 1: Best Practices of Software Engineering.
Overview of NIPP 2013: Partnering for Critical Infrastructure Security and Resilience October 2013 DRAFT.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
1M.Sc.(I.T.), VNSGU, Surat. Structured Analysis Focuses on what system or application is required to do. It does not state how the system should be implement.
The Challenge of IT-Business Alignment
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
Identify steps for understanding and solving the
High Level Architecture Overview and Rules Thanks to: Dr. Judith Dahmann, and others from: Defense Modeling and Simulation Office phone: (703)
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
Systems Engineering In Aerospace Theodora Saunders February AUTOMATION IN MANUFACTURING Leading-Edge Technologies and Application Fairfield University.
Advancing Cooperative Conservation. 4C’s Team An interagency effort established in early 2003 by Department of the Interior Secretary Gale Norton Advance.
CPSC 871 John D. McGregor Module 6 Session 3 System of Systems.
OOI CI LCA REVIEW August 2010 Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger Life Cycle Architecture Review.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
Chapter © 2012 Pearson Education, Inc. Publishing as Prentice Hall.
Enterprise Architecture, Enterprise Data Management, and Data Standardization Efforts at the U.S. Department of Education May 2006 Joe Rose, Chief Architect.
Chapter 6 Supporting Knowledge Management through Technology
S&I Standards Organization Engagement & Communication Plan DRAFT Standards Support Team 1 September 2011.
Draft GEO Framework, Chapter 6 “Architecture” Architecture Subgroup / Group on Earth Observations Presented by Ivan DeLoatch (US) Subgroup Co-Chair Earth.
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
Last Updated 1/17/02 1 Business Drivers Guiding Portal Evolution Portals Integrate web-based systems to increase productivity and reduce.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
Lecture 2.1b: DoD Acquisition Process (SEF Ch 2)
INCOSE Systems of Systems Working Group Alan Harding BAE Systems Dr. Judith Dahmann MITRE Corporation SoS Working Group Co-chairs.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
New Product Development Page 1 Teddy Concurrent Engineering by Teddy Sjafrizal.
Name Project Management Symposium June 8 – 9, 2015 Slide 1 Susan Hostetter, Reed Livergood, Amy Squires, and James Treat 2015 Project Management Symposium.
Climate Change Impacts and Adaptation: The Prairie Adaptation Research Cooperative Mark Johnston Forest Ecosystems Branch, Environment and Resource Management.
1 Lecture 2.4a: SEF SE Planning and the SEP (SEF Ch 16) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Building Systems for Today’s Dynamic Networked Environments A Methodology for Building Sustainable Enterprises in Dynamic Environments through knowledge.
Enterprise Architectures. Core Concepts Key Learning Points: This chapter will help you to answer the following questions: What are the ADM phase names.
International Workshop 26 Jan – 29 Jan 2013 Jacksonville, FL, USA MBSE Workshop SoS Pain Points & Implications for MBSE Dr. Judith Dahmann The MITRE Corporation.
RATIONAL UNIFIED PROCESS PROCESS FRAMEWORK OVERVIEW.
INCOSE IW MBSE Workshop January INCOSE (MBSE) Model Based System Engineering System of Systems and Enterprise Architecture Activity Ron Williamson.
1 The XMSF Profile Overlay to the FEDEP Dr. Katherine L. Morse, SAIC Mr. Robert Lutz, JHU APL
Process 4 Hours.
Discussion Topics for Exploring OMG UPDM Way-ahead
Enabling Collaboration with IT
Systems of Systems Challenges and Strategies
Software engineering -1
Continuity Guidance Circular Webinar
Engineering Autonomy Mr. Robert Gold Director, Engineering Enterprise
Systems Engineering for Mission-Driven Modeling
Systems Architecture & Design Lecture 3 Architecture Frameworks
MODULE 11: Creating a TSMO Program Plan
Presentation transcript:

Systems Engineering in a System of Systems Context Dr. Judith Dahmann The MITRE Corporation

Introduction Systems engineers are increasingly called upon to Implement SE in networked environments Evolve existing and new systems to meet changing user needs Challenge is to leverage SE processes developed and applied for SE of new systems Individual systems are no longer considered as individual bounded entities and are evolved based on extant capabilities Constituents in larger, more variable, ensembles of interdependent systems which interact based on end-to-end business processes and networked information exchange A new set of conditions for their SE processes calls for a new SE framework that reflects the Dynamics and uncertainty of SoS Added complexity of operating in an SoS environment

DoD System of Systems SE Guide Effort led by the Office of the Secretary of Defense Collaborative approach with DoD, Industry, Academia Purpose 6 month effort addressing areas of agreement across the community Focus on technical aspects of SE applicable across SoS management constructs Vehicle to capture and debate current SoS experience Audience SoS and Program Managers and Lead/Chief Engineers SoS Guide Version 1.0 Pilot effort ‘Boots on the Ground’ basis for Structured reviews with practitioners Refine early draft guide content, identify areas for future study Update findings and release Version 1.0 Pilot

Definitions System: A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements; that group of elements forming a unified whole. (JP 1-02 & JP 3-0) SoS: A set or arrangement of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities [DoD Defense Acquisition Guide, 2004]. Taxonomy of SoS Directed SoS objectives, management, funding and authority; systems are subordinated to SoS Acknowledged SoS objectives, management, funding and authority; however systems retain their own management, funding and authority in parallel with the SoS Collaborative No objectives, management, authority, responsibility, or funding at the SoS level; Systems voluntarily work together to address shared or common interest Virtual Like collaborative, but systems don’t know about each other

Active SoS SE Practitioners Provided a basis for understanding SoS in DoD Today

Focus on Acknowledged SoS Increased US DoD emphasis on war fighter capabilities Typically require multiple systems to meet end-to-end capability needs Approach has been to leverage current systems to meet new capability needs However, current systems are still needed for original use And since most systems are developed and managed by the Military Services, responsibility for systems often differs from responsibility for capabilities or SoS Consequently, there are increasing instances of acknowledged SoS in the US DoD Characterized by dual management, funding and technical authorities Source of management issues which impact SE V1 of the guide provides an initial resource for SE teams working in this environment Why not directed? Not many, bulk are acknowldged Collaborative and Virtual – No SoS SE teams to work with Acknowledged SoS growing in the US DoD They have received little attention to date

SE Model for SoS Based on 7 Core Elements of SoS SE Translating capability objectives New SoS SE role Assessing (actual) performance to capability objectives Orchestrating upgrades to SoS Persistent SoS overlay framework Understanding systems & relationships (includes plans) Developing, evolving and maintaining SoS design/arch Developing & evolving SoS architecture Addressing new requirements & options Addressing & solution options SoS upgrade process External influences Monitoring & assessing changes External Environment

SE Processes Support Core Elements DoD Defense Acquisition Guide presents 16 basic SE processes In an SoS, SE team adapts these processes to execute core SE elements Focus for SoS SE is on technical management since implementation is in systems SoS SE Core Elements Rqts Devel Logical Analysis Design Solution Implement Integrate Verify Validate Transition Decision Tech Planning Assess Rqts Mgt Risk Mgt Config Mgt Data Mgt Interface Translating Capability Objectives X Understanding Systems & Relationships Assessing Performance to Capability Objectives Developing & Evolving an SoS Architecture Monitoring and Assessing Changes Address Requirements & Solution Options Orchestrating Upgrades Technical Processes Technical Management Processes Translating capability objectives Understanding systems & relationships Assessing performance To capability objectives Developing & evolving SoS architecture Monitoring & assessing changes Addressing requirements and solution options Orchestrating upgrades to SoS

Core Elements of SoS SE (1 of 3) Translating SoS capability objectives into high level requirements over time SoS objectives based on broad capability objectives SE team plays strong role in establishing requirements and understanding dynamics of the environment Translating capability objectives Identifying and understanding the systems that impact SoS objectives Focus on components and dynamics vs boundaries Extends beyond technical to broader context of management, organizational, development plans, funding, etc. Understanding systems & relationships (includes plans) Monitoring & assessing changes Anticipating and assessing impacts of potential changes on SoS performance Given scope of SoS authority, key to SoS SE is identifying and addressing changes in systems and other areas (e.g. threat) which may impact the SoS

Core Elements of SoS SE (2 of 3) Developing and evolving SoS architecture This includes Concept of operations Systems, functions and relationships and dependencies, both internal and external End-to-end functionality, data flow and communications within the SoS. Provides the technical framework for assessing options and implications for meeting requirements over time Persistence, tolerance for change Developing, evolving and maintaining SoS design/arch Developing & evolving SoS architecture An architecture is the structure of components, their relationships, and the principles and guidelines governing their design evolution over time (IEEE Std 610.12 and DoDAF). The architecture of an SoS is a persistent technical framework for governing the evolution of an SoS over time.

Core Elements of SoS SE (3 of 3) SoS requirements and solution options Requirements addressed at both SoS & systems Recommend SoS requirements based on both priority and practicality SoS and system SE teams identify and assess options Result is plan for development for next increment Addressing new requirements & options Addressing & solution options Orchestrating upgrades to SoS Orchestrating SoS Upgrades Upgrades implements by systems under system SE teams SoS SE team plans, facilitates, integrates and tests upgrades to the SoS Development based on approaches (bus stop, wave) which accommodate asynchronous system developments Assessing (actual) performance to capability objectives Assessing SoS Performance Based on measures of SoS user results applied in different settings (test, exercises, M&S, operations) Opportunity to identify changes and emergent behavior

View of SoS Upgrade (1 of 2) Assessing performance to capability objectives For each increment Recommend rqts for this increment Id Assess SoS capabilities and limitations Addressing new requirements & options Addressing & solution options Orchestrating upgrades to SoS Identify candidate systems to support functions Validate sets of systems SoS Assess options Verify sets of systems Negotiate with systems Integrate sets of systems Develop plan Coordinate, monitor and facilitate systems’ development, test and evaluation Systems

View of SoS Upgrade (2 of 2) Understanding Systems & relationships Developing & Evolving SoS Architecture Translating Capability Objectives Monitoring & Assessing Changes Assessing SoS Performance Orchestrating upgrades to SoS Addressing new requirements & options Addressing & solution options SoS Systems Multiple, possibly concurrent increments

In Conclusion ‘Acknowledged’ SoS, challenge the practice of SE Research supporting the DoD SoS SE Guide have identified seven core elements of SoS SE and their relations