Software in System Engineering: Affects on Spacecraft Flight Software

Similar documents
Effective Reduction of Avoidable Complexity in Embedded Systems

The Method Framework for Engineering System Architectures (MFESA)

Introduction to Software Product Lines Patrick Donohoe Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213

Designing the Infrastructure for an Enterprise IT System

The Method Framework for Engineering System Architectures (MFESA)

Practical Risk Management: Framework and Methods

Acquisition Overview: The Challenges

Mission Success in Complex Environments (MSCE)

Supporting Safety Evaluation Process using AADL

A Primer on. Software Licensing. Charlene Gross Software Engineering Institute. Do You Own It or Not? Charlene Gross, April 19-23, 2010

Optional Inner Title Slide

The Potential for Lean Acquisition of Software Intensive Systems

System-of-Systems Influences on Acquisition Strategy Development

Evaluating CSIRT Operations

Overview of a Proactive Software Product Line Acquisition Approach

Safety Evaluation with AADLv2

MEASURING PROCESS CAPABILITY VERSUS ORGANIZATIONAL PROCESS MATURITY

Complexity and Software: How to Meet the Challenge. NDIA CMMI Technology Conference

CMMI Version 1.2. Model Changes

CMMI A-Specification. Version 1.7. November, For CMMI Version 1.2. This document is controlled by the CMMI Steering Group.

CMMI High Maturity An Initial Draft Interpretation for V1.3

What s New in V1.3. Judah Mogilensky Process Enhancement Partners, Inc.

Architecture Centric Evolution

I ve Evaluated My Architecture. Now What?

SOA Research Agenda. Grace A. Lewis

Overview of a Proactive Software Product Line Acquisition Approach

It Takes an Ecosystem Gary Chastek John D. McGregor

Applying Software Architecture Principles in a DoD Acquisition

Disciplined Agility for the Development of Softwareintensive. Dr. Peter Hantos, I.S.T.J. Consultant

Meter Data Management System (MDMS) Sharing. Ricky Ip CLP Project Manager

Toolbox for Architecture Framework Discussions at The Open Group. SKF Group, February 2018

Lean Aerospace Initiative Annual Symposium

Understanding Model Representations and Levels: What Do They Mean?

Command and Control Software Development Lessons Learned. Lt Col Michael D. Sarchet Deputy Director, Space Systems Command and Control Division

Using Pilots to Assess the Value and Approach of CMMI Implementation

SEPG Using the Mission Diagnostic: Lessons Learned. Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213

Real time Propagation of Spacecraft Tasking Interface Changes

Rational Software White Paper TP 174

Introduction of RUP - The Rational Unified Process

OSATE overview & community updates

CMMI Update. Mary Beth Chrissis, as represented by: Pat O Toole Software Engineering Institute. Pittsburgh, PA May 15, 2008

Architecture-Centric Procurement

Oracle Unified Method (OUM) The OUM Implement Core Workflow The Key to Understanding and Applying OUM. An Oracle White Paper April 2012

SOA Governance is For Life, Not Just a Strategy

Enterprise Portal Modeling Methodologies and Processes

Estimating Software Sustainment Costs

CMMI Version 1.3: Are you Ready for Release?

Architectural Considerations for Validation of Run-Time Application Control Capabilities for Real-Time Systems

How to use SAP PowerDesigner to model your landscape architecture

Process Improvement for All: What to Expect from CMMI Version 1.3

Advanced Engineering Environments for Small Manufacturing Enterprises

The Business Case for Systems Engineering: Comparison of Defense-Domain and Non- Defense Projects

SUSE Unified Delivery Process

Exam Questions OG0-091

Independent Verification and Validation (IV&V)

Chapter 6. Software Quality Management & Estimation

1.264 Lecture 5 System Process: CMMI, ISO

Digital Effectiveness From Factory IT to Right-Speed IT

DEPARTMENT OF DEFENSE HANDBOOK ACQUISITION OF SOFTWARE ENVIRONMENTS AND SUPPORT SOFTWARE

'HYHORSPHQWVLQ3URGXFW/LQHV DQG$UFKLWHFWXUH(YDOXDWLRQ

Functional Architecture as the Core of Model-Based Systems Engineering

Improving Acquisition in Government Requirements Management Leading Practices: CMMI-ACQ Visualization

Systems and software engineering Software life cycle processes

Oracle Systems Optimization Support

Service Virtualization

Highlights of CMMI and SCAMPI 1.2 Changes

Applying CMMI-SVC Process Areas to CMMI-DEV Projects

Software Engineering II - Exercise

Software Development Methodologies

FUTURE DIRECTIONS FOR PRODUCT LIFECYCLE MANAGEMENT (PLM) AND MODEL-BASED SYSTEMS ENGINEERING (MBSE)

Sistemi ICT per il Business Networking

SYSTEMS MODELING AND SIMULATION (SMS) A Brief Introduction

Achieving SA-CMM Maturity Level A DoD Acquisition Management Experience

Collaborative Government / Contractor SCAMPI Appraisal

Complex Systems of Systems (CSOS) : Software Benefits,Risks,and Strategies

An Overview of the Smart Grid Maturity Model (SGMM)

T E A L C O N S U L T I N G L T D I S O A G U I D E

Software Development Methodologies. CSC 440: Software Engineering Slide #1

QUEST Boston As Requirements Go, So Goes the Project. Thursday, April 7 th, :00 PM 2:00 PM. PRESENTER: Charlene Gross

Developing Framing Assumptions (FAs) Job Support Tool (JST)

CMMI Level 2 for Practitioners: A Focused Course for Your Level 2 Efforts

Agile and CMMI : Disciplined Agile with Process Optimization

Project Management by Functional Capability. NDIA CMMI Technology Conference and User s Group November 15, 2007

SEPG Using the Mission Diagnostic: Lessons Learned. Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213

Service Virtualization

Adapting Agile to the. Framework. Mary Ann Lapham, PMP, CSM Principal Engineer Software Engineering Institute

Collaborative DevOps with Rational and Tivoli

The Value of TSP in Agile Practices

This chapter illustrates the evolutionary differences between

Achieving Agility and Stability in Large-Scale Software Development. Ipek Ozkaya Senior Researcher, Research, Technology, and System Solutions Program

Learning Technology Implementation Guide: econtent Development and Integration

Change Management and Adoption for Cloud ERP Prepared by Michael Krigsman February 2012

Chapter 6: Software Evolution and Reengineering

This document is a preview generated by EVS

Supply-Chain Risk Analysis

CSE 435 Software Engineering. Sept 14, 2015

The Business Case for Systems Engineering: Comparison of Defense-Domain and Non- Defense Projects

CGEIT Certification Job Practice

Product-Line Development Metrics

An Embedded SCAMPI-C Appraisal at the National Security Agency. NDIA CMMI Technology Conference and User s Group November 15, 2007

Transcription:

Software in System Engineering: Affects on Spacecraft Flight Software Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Charles (Bud) Hammons, PhD Mary Ann Lapham Nov 4, 2009

Agenda Introduction Issues Resulting from Software/Systems Relationship Early identification/mitigation of software engineering issues Traditional system engineering inappropriate to incremental development environments Inter-increment dependencies Unprecedented software integration complexity Software architectures Summary Contact Information 2

Introduction What is the relationship Software/System Engineering?? Historically, software is considered an implementation detail Software considered late in system lifecycle An alternative view software and system engineering need to work collaboratively from start of development Not here to debate either premise but to look at impacts Historic approach causes or exacerbates many issues 3

Early Identification/Mitigation of Issues 1 Software engineering issues appear or start early in programs Space programs typically have ground and spacecraft components/segments Most times segments treated separately Miss system level software engineering issues or get misconceptions and disconnects between segments Requirements Interpretation is key Segment versus system could be inconsistent resulting in noninteroperable designs and implementations Need system software team involved in technical oversight = potential solution 4

Early Identification/Mitigation of Issues 2 Miss system level software engineering issues or get misconceptions and disconnects between segments (continued) Defining or declaring operational configuration Different perspective from ground and spacecraft Need to know static structure of system? Known defects? Deployed, development, and maintenance configurations Roll back information Coordinated and interdependent high-level software design decisions Define maintenance model early including explicit use cases to avoid inviting shortfalls in capability 5

Early Identification/Mitigation of Issues 3 Miss system level software engineering issues or get misconceptions and disconnects between segments (continued) Life-cycle costs Effect on software complexity, costs, etc vetted where Segments have different view than system Potential higher costs especially during operations/maintenance System wide role to integrate all the various software costs to ensure correctness, completeness, and consistency Testing System versus segment testing Spacecraft interested in edge-to-edge (within segment) System interested in end-to-end Include both positive and off-nominal paths Coordination of segment and system views and plans essential 6

Traditional System Engineering with Incremental Environment Merging traditional system engineering with incremental development Satellite constellations may be done in increments User expectations can change and grow between increments Requirement, configuration, and version interdependencies need to be well understood Allocation between hardware and software may change across increments Institute concurrent development approach Provide venue for cross-domain systems engineering issues 7

Inter-increment dependencies Each increment considered entire system unto itself Subsequent increments treat previous increments as legacy systems Infers set of parallel or staggered development efforts Set of artifact needs Places unexpected strains on resources (shared or not) and development teams Strategies vary for individual programs Design each increment to be modifiable (solutions must be able to be modified and extended) 8

Unprecedented software integration complexity Major integration risk for 10 7 or more equivalent lines of code Risk will surface in later stage integration and test Usually when program vulnerable due to schedule and cost experience versus early promises Empanel vigorous systems integration team Beginning of program Charged to address downstream integration issues including software integration Institute cross-program configuration control at requirements level to aid in managing one of the primary drivers of complexity growth Institute test and integration teams charged with ensuring that dependencies are properly tested and existing operational capabilities not interrupted Test early and often 9

Software architectures Multiple increments leads to potential different architectures for each increment or satellite in a constellation Design variations may be needed to mitigate deltas some in hardware but some in software Coordination across prime items between segments required Messages exchanged across segments may have different results on various increments Configuration control difficult when CCB oversight spans development, sustainment, and multiple contracts Leveraging COTS across increments may change architectures Variable nature of COTS releases Different functionality available, evolution in interfaces Integrate early and often Enable strong communication and collaboration 10

Summary Early attention to software engineering is critical in reducing software risk throughout the program s lifecycle Issues manifest in all phases of the lifecycle requirements, development, test and integration Solutions include: Need system software team involved in technical oversight from program inception Ensure high level software decisions are coordinated across segment and contractual boundaries Provide venue for cross-domain systems engineering issues, e.g. combined software and systems CCB Modifiable solutions Test and integrate early and often Enable strong communication and collaboration 11

Contact Information Slide Format Mary Ann Lapham/Bud Hammons Senior Member Technical Staff Acquisition Support Program Telephone: +1 412-268-5800 Email: info@sei.cmu.edu U.S. mail: Software Engineering Institute Customer Relations 4500 Fifth Avenue Pittsburgh, PA 15213-2612 USA World Wide Web: www.sei.cmu.edu www.sei.cmu.edu/contact.html Customer Relations Email: customerrelations@sei.cmu.edu Telephone: +1 412-268-5800 SEI Phone: +1 412-268-5800 SEI Fax: +1 412-268-6257 12