Advancing the knowledge of systems engineering

Slides:



Advertisements
Similar presentations
Value of Systems Engineering INCOSE Data
Advertisements

INCOSE Presentation San Francisco Chapter 13 October 2009 Mapping CMMI to Systems Engineering Adrienne Friedman.
College of Continuing Education Systems Engineering Non-credit Certificate.
1 INCOSE Chesapeake Chapter Enterprise SE Panel Discussion L. Mark Walker/LMC 21 March 2007.
1 PROJECT MANAGEMENT ROLE OF KEY PERSONNEL Bernd Madauss International Space University Strasbourg February, 2011
S Y S T E M S E N G I N E E R I N G.
© 2009 The MITRE Corporation. All rights Reserved. Evolutionary Strategies for the Development of a SOA-Enabled USMC Enterprise Mohamed Hussein, Ph.D.
1 Chapter 2: Product Development Process and Organization Introduction Importance of human resources: Most companies have similar technology resources.
Honourcode, Inc. Systems Engineering Return on Investment (SE-ROI) Dr. Eric Honour +1 (850) Funding provided by Honourcode,
2003 Indigo Technology, Inc. All Rights Reserved Integrated Process Teams Process Management Quality Assurance Configuration and Data Management Program.
1 Software Requirement Analysis Deployment Package for the Basic Profile Version 0.1, January 11th 2008.
18 th International Forum on COCOMO and Software Cost Modeling October 2003 Use of Historical Data by High Maturity Organizations Rick Hefner, Ph.D.
1 Introduction to System Engineering G. Nacouzi ME 155B.
System-of-Systems Cost Modeling: COSOSIMO July 2005 Workshop Results Jo Ann Lane University of Southern California Center for Software Engineering.
Information Systems Development and Acquisition Chapter 8 Jessup & Valacich Instructor: Ramesh Sankaranarayanan.
Secure System Administration & Certification DITSCAP Manual (Chapter 6) Phase 4 Post Accreditation Stephen I. Khan Ted Chapman University of Tulsa Department.
Systems Engineering Management
IIBA Denver | may 20, 2015 | Kym Byron , MBA, CBAP, PMP, CSM, CSPO
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Engineering Systems of.
INCOSE 1 st reactions. One other area that struck me has the sheer number of levels of proficiency—in ours we are going with 5 and the first one is limited.
Technical Integrity Assurance For Product Development W. Henson Graves Lockheed Martin Aeronautics Company Russ Campbell.
What is Business Analysis Planning & Monitoring?
Using Six Sigma to Achieve CMMI Levels 4 and 5
Continuation From Chapter From Chapter 1
CMMI Course Summary CMMI course Module 9..
CPTE 209 Software Engineering Summary and Review.
Process Assessment Motivation SEI Capability Maturity Model
Software Project Management Introduction to Project Management.
Moving into Design SYSTEMS ANALYSIS AND DESIGN, 6 TH EDITION DENNIS, WIXOM, AND ROTH © 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 1 Roberta M. Roth.
Business Analysis and Essential Competencies
1 Process Engineering A Systems Approach to Process Improvement Jeffrey L. Dutton Jacobs Sverdrup Advanced Systems Group Engineering Performance Improvement.
1 Lecture 5.2a: SEF Ch 8 SE Outputs Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
A Project ’ s Tale: Transitioning From SW-CMM to CMMI-SE/SW Warren Scheinin Systems Engineer, NG Mission Systems CMMI Technology Conference & User Group.
1 Systems Engineering Process Review Mark E. Sampson EMIS 8340 Systems Engineering Tool—applying tools to engineering systems.
NDIA Systems Engineering Supportability & Interoperability Conference October 2003 Using Six Sigma to Improve Systems Engineering Rick Hefner, Ph.D.
Page 1 ISO/IEC JTC 1/SC 7/WG 7 N Summary of the Alignment of System and Software Life Cycle Process Standards The material in this briefing.
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
Chapter 7: A Summary of Tools Focus: This chapter outlines all the customer-driven project management tools and techniques and provides recommendations.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
Modeling and simulation of systems Model building Slovak University of Technology Faculty of Material Science and Technology in Trnava.
Process Improvement. It is not necessary to change. Survival is not mandatory. »W. Edwards Deming Both change and stability are fundamental to process.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 What is Solution Assessment & Validation?
Bill Fournier Nov 2014 Systems Engineer for Non SE Bill Fournier
1 | 2010 Lecture 3: Project processes. Covered in this lecture Project processes Project Planning (PP) Project Assessment & Control (PAC) Risk Management.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
1 Overview of Maintenance CPRE 416-Software Evolution and Maintenance-Lecture 3.
Foundations of Geospatial System Development Todd S. Bacastow Professor of Practice for Geospatial Intelligence John A. Dutton e-Education Institute The.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
XXX, Inc. 1 Technical Capabilities  Requirements Engineering  Analysis and Design  Implementation  Quality Assurance  Project Life Cycle  Requirements.
Minimizing SCAMPI Costs via Quantitative Methods Ron Ulrich, Northrop Grumman Rick Hefner, Northrop Grumman CMMI.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 Click to edit Master title style What is Business Analysis Body of Knowledge?
Software Engineering (CSI 321) Software Process: A Generic View 1.
MSA Orientation – v203a 1 What’s RIGHT with the CMMI?!? Pat O’Toole
Project Management Strategies Hidden in the CMMI Rick Hefner, Northrop Grumman CMMI Technology Conference & User Group November.
SE513 Software Quality Assurance Lecture12: Software Reliability and Quality Management Standards.
1 Lecture 2.3: SE Process (SEF Ch 3) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
SYSTEMS ENGINEERING PROCESSES IN NASA AND COMMERCIAL PROJECTS Paul Componation Kathryne Schomberg Susan Ferreira Jordan Hansen.
SYSE 802 John D. McGregor Module 0 Session 3 Systems Engineering QuickView.
Lesson Point of Contact: Name: John Rice Phone: Slide 1
2012 Spring Simulation Interoperability Workshop
DoD SE Processes (DAG section)
Succeeding as a Systems Analysts
IEEE Std 1074: Standard for Software Lifecycle
Quality management standards
Use of CMMI in an Acquisition Context Using CMMI for Process Improvement at USAF Space and Missile Systems Center (SMC) Dr. Jack R. Ferguson
DOD’S PHASED SYSTEM DEVELOPMENT PROCESS
Requirements Development in CMMI
Capability Maturity Model
Presentation transcript:

Advancing the knowledge of systems engineering Toward an Ontology for Measuring Systems Engineering Return on Investment Advancing the knowledge of systems engineering Eric Honour +1 (850) 479-1985 ehonour@hcode.com Dr. Ricardo Valerdi +1 (617) 253-8583 rvalerdi@mit.edu Toward Ontology for SE-ROI Version

Topics SE-ROI Project “Ontology” concept COSYSMO work toward ontology Categorization from current standards Future directions Toward Ontology for SE-ROI

Systems Engineering Return on Investment Summary of the SE-ROI Project Toward Ontology for SE-ROI

“System Thinking” Design Heuristic Claim of SE Better systems engineering leads to Better system quality/value Lower cost Shorter schedule SYSTEM DESIGN DETAIL PRODUCTION INTEGRATION TEST Traditional Design Time Risk Saved Time/ Cost “System Thinking” Design Time Risk Toward Ontology for SE-ROI

Value of SE – 2004 Results Problems/challenges: Value = 1.0 if program met cost/schedule goals Each dot is one program, with sizes between $1M and $6.5B The upper left chart shows that the data supports the original hypothesis, that cost and schedule performance are improved (up to a point) by the use of more SE effort. (The vertical axis on this chart is the inverse average of cost and schedule overruns.) The lower right chart is an independent, subjective check on the hypothesis, based on the subjective inputs of respondents. Their evaluation of “comparative success” on a scale of 0-10 also shows higher project success with greater SE effort. Problems/challenges: Quantitative data on SE not available in program databases All data points were subjective Detailed structure not available Greater SE Effort led to better cost/schedule compliance and better predictability Source: SECOE 01-03 INCOSE 2003 Toward Ontology for SE-ROI Measurable Systems Engineering

SE-ROI Project Interviews Just-completed programs Desired Results Key PM/SE/Admin Translate program data into project structure Desired Results Statistical correlation of SE methods with program success. Leading SE indicators that can be used during a program. Identification of good SE practices under different conditions. Program characterization Program success data SE data (hours, quality, methods) Statistical correlation Toward Ontology for SE-ROI

What is this word and how does it relate to systems engineering? “Ontology” Concept What is this word and how does it relate to systems engineering? Toward Ontology for SE-ROI

Current State of SE Definition Fragmented by domain opinions Military – DOD/MOD Space - NASA/ESA Commercial products Aircraft Automobiles Nuclear waste Process engineering Tool vendors Etc. Etc. Etc. Fragmented by discipline opinions Technical leaders System architects System analysts Requirements engineers Operations analysts Design engineers Fragmented by standards ANSI/EIA-632 IEEE-1220 ISO-15288 CMMI MIL-STD-499C Toward Ontology for SE-ROI

Ontology “…a branch of metaphysics concerned with the nature and relations of being” aesthetics interfaces functions structure inputs components methods outputs categories understanding POSIWID – The Purpose of a Systems Is What It Does Jack Ring The purpose of systems engineering is different in the eyes of different people, because they perceive different actions/results from SE Toward Ontology for SE-ROI

Purpose of this Paper Explore the variety of what people see in SE Formulate some general categories Interpret historical SE effort data Provide a structure for the data-gathering in the SE-ROI project. Toward Ontology for SE-ROI

COSYSMO work toward ontology An exploration of ontology as performed in the COSYSMO project Toward Ontology for SE-ROI

COSYSMO Effort Profile How is Systems Engineering effort distributed over time? Phase Conceptualize Develop Operational Test & Eval Transition to Operation %Effort (STDEV) 23 (12) 36 (16) 27 (13) 14 (9) Toward Ontology for SE-ROI

Effort Distribution Across ANSI/EIA 632 Fundamental Processes Average Standard Deviation Acquisition & Supply 7% 3.5 Technical Management 17% 4.5 System Design 30% 6.1 Product Realization 15% 8.7 Technical Evaluation 31% Toward Ontology for SE-ROI

Systems Engineering Effort Profile Toward Ontology for SE-ROI

Categorization from Current Standards The start of an ontology, by identifying the widely-accepted categories. Toward Ontology for SE-ROI

Categories in the Standards Mission/Purpose Definition Requirements Management System Architecting System Implementation Technical Analysis Technical Management/Leadership Verification & Validation CMMI ANSI/EIA-632 MIL-STD-499C IEEE-1220 ISO-15288 Colored boxes on following slides show the terminology used by each standard Toward Ontology for SE-ROI

Mission/Purpose Definition Define the mission or purpose of the new/changed system. Typically described in the language of the system users rather than in technical language CMMI Develop customer requirements ANSI/EIA-632 Not included MIL-STD-499C Not included IEEE-1220 Define customer expectations ISO-15288 Stakeholder needs definition Toward Ontology for SE-ROI

Requirements Management Creation and management of requirements Efforts to define, analyze, validate, and manage the requirements CMMI Requirements development Requirements mgmt ANSI/EIA-632 System design Requirements definition MIL-STD-499C System requirements analysis and validation IEEE-1220 Requirements analysis ISO-15288 Requirements analysis Toward Ontology for SE-ROI

System Architecting Define the system in terms of its component elements and their relationships Diagrams that depict the system, its environment, components, and relationships CMMI Technical solution ANSI/EIA-632 System design Solution definition MIL-STD-499C System product technical requirements analysis and validation Design or physical solution representation IEEE-1220 Synthesis ISO-15288 Architectural design System life cycle mgmt Toward Ontology for SE-ROI

System Implementation Development/completion of the system Specific system-level efforts in the standards are system integration and transition to use ANSI/EIA-632 Product realization Implementation Transition to use CMMI Product integration MIL-STD-499C Not included IEEE-1220 Not included ISO-15288 Implementation Integration Transition Toward Ontology for SE-ROI

Technical Analysis System-level technical analysis Assessment of system performance Trade-off analysis of alternatives CMMI Measurement and analysis ANSI/EIA-632 Technical evaluation System analysis MIL-STD-499C Functional analysis, allocations and validation Assessments of system effectiveness, cost, schedule, and risk Tradeoff analyses IEEE-1220 Functional analysis Requirements trade studies and assessments Functional trade studies and assessments Design trade studies and assessments ISO-15288 Requirements analysis Toward Ontology for SE-ROI

Technical Management/Leadership Guiding the engineering teams involved in system design programs Size/complexity of teams demands leadership CMMI Project planning Project monitoring & control Supplier agreement mgmt Process/product quality assur. Configuration mgmt Integrated project mgmt Decision analysis/resolution Quantitative project mgmt Risk mgmt ANSI/EIA-632 Technical Mgmt Planning Assessment Control MIL-STD-499C Planning Monitoring Decision making, control, and baseline maintenance Risk mgmt Baseline change control Interface mgmt Data mgmt Subcontract mgmt Technical reviews/audits IEEE-1220 Technical mgmt Track analysis data Track requirements and design changes Track performance Track product metrics Update specifications Update architectures Update plans Maintain database ISO-15288 Planning, Assessment, Control Decision mgmt Config mgmt Acquisition, Supply Resource mgmt Risk mgmt Toward Ontology for SE-ROI

Verification & Validation Verification: comparison of the system with its requirements through objective evidence. Validation: comparison of the system or requirements with the intended mission ANSI/EIA-632 Technical Evaluation Requirements validation System verification End products validation CMMI Verification Validation MIL-STD-499C Design or physical solution verification and validation IEEE-1220 Requirement verification Functional verification Design verification ISO-15288 Verification Validation Quality mgmt Toward Ontology for SE-ROI

Future Directions Where is SE-ROI going? Toward Ontology for SE-ROI

Project Advisory Group Group of interested people/organizations Communicate via web, telecon, meetings Help define the data organization Build public interest in the project Provide access to real programs View interim (protected) data as it develops Current members come from: AF Institute of Technology Northrop Grumman DOD Office of Secy of Defense DRS Johns Hopkins Univ MIT The Mitre Corp NAVAIR Raytheon Rand Corporation Rafael Systems & Software Consortium Univ of South Australia USN Chief Engineer For information, see http://www.hcode.com/seroi/ Toward Ontology for SE-ROI

Summary Systems engineering current state of knowledge is fragmented Broadly-accepted ontology is needed SE-ROI project needs categorization now Structure the data to be correlated Discover leading SE indicators Identify SE best practices and methods Categorization across standards helps develop the needed ontology Toward Ontology for SE-ROI

Questions? Eric Honour +1 (850) 479-1985 ehonour@hcode.com Dr. Ricardo Valerdi +1 (617) 253-8583 rvalerdi@mit.edu For information, see http://www.hcode.com/seroi/ Toward Ontology for SE-ROI

Survey of SE-ROI Knowledge 1992 Gruhl (NASA) Project Definition – NASA Program definition 10-15% reduces cost overruns 1990 Ancona/ Caldwell Boundary Management Study Boundary management averages 14%; more is better 2000 Miller (MIT) Large Engineering Projects Study Programs value cost over schedule over tech Leadership important 1995 Franz (Boeing) Impact of Systems Engineering on Quality and Schedule Better SE led to significant cost reduction 2003 Barker (IBM) Systems Engineering Effectiveness Better SE reduced parametric costs by 30% 2004 Kludze (NASA) Impact of Systems Engineering on Complex Systems General belief that SE improves program cost 2004 Honour (SECOE) Value of Systems Engineering Greater SE 10-15% reduces cost/schedule overruns Toward Ontology for SE-ROI

Next Steps Define interview data sheets Use this categorization Identify and interview trial projects Obtain initial data Evaluate the interview data sheets Identify and interview projects Ongoing effort for 2-3 years Perform statistical correlation work Ongoing effort for duration of project Interim reports to participating organizations Final report expected 2009 Toward Ontology for SE-ROI