Page 1 Software Engineering Institute Carnegie Mellon University Defense Acquisition University...

page 1

Software Engineering InstituteCarnegie Mellon University

Defense Acquisition University

Sponsored by the U.S. Department of Defense© 2004 by Carnegie Mellon University

School of GovernmentUniversity of North Carolina

OSD PA&E CAIG

System of Systems Integration Cost Driver Research

March 2004

Jeannine M. Siviy: SEPG 0545Jeannine M. Siviy: SEPG 0545

page 2

Carnegie MellonSoftware Engineering Institute

Agenda

Research Effort Background 1230-1300• Initial Model and Hypotheses • Collaborators• ScheduleDiscussion 1300-1420• Session Goals• Ground rules• Q&A• Wrap up Next Steps 1420-1430

page 3


Research Goals

To identify leading indicators of SoS cost and schedule• Gain insight into drivers of size, complexity, cost, and schedule • Gain insight into drivers of process efficiency and effectiveness

Output: • Analytical tools and methodologies to support Joint Capabilities

investment decisions• Practical management methodologies to assist SoS/FoS

implementers and operators

page 4


Research StatusFunded in FY04 as part of broad software research initiativeCurrent research partnership

• Software Engineering Institute (SEI)- Dr. David Zubrow, SEI Software Engineering Measurement &

Analysis (SEMA)- Mr. Bill Anderson, Integration of Software Intensive Systems

(ISIS)• University of North Carolina (UNC)

- Dr. Mary Maureen Brown, UNC School of Government• Defense Acquisition University (DAU)

- Ms. Martha Spurlock, Director, Cost Analysis Curriculum- Mr. Robert Skertic, Software, Technical & Engineering Dept.

CAIG Study POC’s • Rob Flowe (703) 692-8052 [email protected]• Tom Coonce (703) 697-3845 [email protected]

Seeking collaboration opportunities, ideas, data!

page 5


Focus Group GoalsWhat key [issues, drivers, factors] differentiate the programmatic issues associated with SoS acquisition from single system development?

To what extent do the stakeholder, end-user, and developer relationships influence the technical architecture design and implementation?

To what extent is the strategic intent of the SoS effort accompanied by the necessary funding, operational, and personnel incentives to promote successful accomplishment?

page 6


Some General Precepts

“Interoperability” is a multi-dimensional aspect of system engineering.• Scope is far greater than simply interoperability of data –

requires integration of enterprise rules• Scope includes degrees of operational, system, and technical

coupling, ownership, …• Scope includes integration at the programmatic level

We can never anticipate fully the boundaries within which a given system will be expected to operate.• One man’s system-of-systems is another’s system.• There will always be new things to integrate into the system. • Integrating systems in a network can affect all other systems

in the network in unintended ways.

page 7


More General Precepts

Size matters:• As integration in the small gets larger, new problems

creep in: management, organizational.• As systems get more complex, interoperability issues

increase.• As operators become more agile, systems must

become dynamically reconfigurable.

Interoperability must be quantifiable to be achievable.

Interoperability must be sustainable and sustained.

page 8


A View of the Problem SpaceIncomplete understanding of scope and nature of the engineering to be accomplished• There are weaknesses in translating high level

concepts of operations into a set of system requirements that lead to interoperability.

Ongoing inertia toward separate programs executed independently

Technologies do not currently exist that permit quantification of interoperability.

page 9


System “C”

We know quite a lot about constructing systems from components (over which we may have little or no control).

We know very little about constructing an interoperable network of systems…the key distinction being that the network is unbounded (or very loosely bounded) and has no single controlling authority.

An Instance of the Problem

We know something about composing systems of systems from individual systems (over which we may have little or no control).

System “B”

System “A”

Network “X”

Unplanned, unexpected, emergent behavior here…

page 10


Interoperability Activities Model

Activities performed to manage the acquisition of a system.

Activities performed to create and maintain a system. Focus is on architecture, standards, components.

Activities performed to operate a system. Focus is on interactions with other systems and data distribution.

OperationalSystem

Sy

ste

mC

on

str

uct

ion

ProgramManagement

page 11


SoSI Interoperability Model

System

Co

nst

ruct

ion

PM

SystemC

on

stru

ctio

n

PM

System

Co

nst

ruct

ion

PM

Programmatic

Interoperability

Operational Interoperability

Constructive

Interoperability

page 12


Operational Interoperability

Fixing interoperability problems at the Operational level is key: Operational problems reduce the capabilities of the warfighter.

• insufficient sharing of data among systems- sometimes operators make up for the deficiencies

manually- sometimes unique interfaces obscure sharing that is

possible- users uncover the needs

• fixing problems in the field costs scarce resources- problems may not be found until time of greatest

need

page 13


Constructive Interoperability

Developers may not know how their system is to interoperate with others; frequently they:• are given “just a piece” of the overall system of systems• SoS architectures are often insufficiently specified• have no model indicating the meaning of data (semantics)• are unaware of timing and sequencing of interactions

Technologies exist, but not clear how or when to use them.• Exceptions: technologies for real-time, high-speed

applications and multilevel security are not sufficient• Information Exchange Requirements make sense in

point-to-point communication, less so in a net-centric environment

page 14


Relationship among DoD AF Views

page 15


Programmatic Interoperability

Programmatic problems dominate constructive ones.

SoSs often lack an ultimate authority for overall system (of systems) engineering.• Requirements for interoperability either are not given or are

vague.• Dependence on other systems can lead to local sub-

optimization: no universal enforcement of policy. • Program offices are stove-piped, doing their own thing

- even if they wanted to, it is hard to share information

“Unfunded mandates”• interoperability may not be sufficiently funded• interoperability is the first quality to be lost when schedule or

money are tight• IAM is often not funded and therefore not developed

page 16


Characterizing InteroperabilityDimensions apply variously to three system aspects:• the whole system of systems• the components that make up the system of systems

(“nodes”)• the relationships between the components (“arrows”)

Characteristics cover such dimensions as:• Evolution• Ownership• Technology availability• Communication• Planning and management• Usage patterns• Dynamism• Semantic consistency• Data management

page 17


Concept Map of SoSI Attributes as Related to Acquisition Outcomes

CostSchedule

Performance(Outcomes)

DrivesTotalEffort

InherentEffort

PartOf

InducedEffort

PartOf

Product-RelatedEffort Drivers:e.g., size, &complexity

Process-RelatedEffort Drivers:

e.g., efficiency &effectiveness

EnterpriseRules

InterfaceAttributes

ElementAttributes

ProcessAttributes

EnvironmentalAttributes

page 19


Discussion

page 20


• Keep focused

• Maintain momentum

• Get closure on questions

• Only one person speaks at a time

• Be concise, get to the point

• Stay on the topic and minimize diversions

Ground Rules

page 21


Questions for Discussion

What key [issues, drivers, factors] differentiate the programmatic issues associated with SoS acquisition from single system development?

• What differentiating activities in your experience are key to the success of SoS acquisition?

• How do the differences impact cost, schedule, performance and functionality?

page 22



To what extent do the stakeholder, end-user, and developer relationships influence the technical architecture design and implementation? Are the DoDAF views useful for translating operational capabilities into a roadmap for SoS integration? What impact do these relationships have on program cost, schedule, performance and functionality?

page 23



To what extent is the strategic intent of the SoS effort accompanied by the necessary funding, operational, and personnel incentives to promote successful accomplishment? How do the requisite funding, operational, and personnel incentives impact program cost, schedule, performance and functionality?

page 24


Next Steps

Field StudiesSuccessful programsChallenged programs

Ongoing Interviews with Subject Matter ExpertsPoints of Contact

Appreciate your comments on draft results and opportunity to continue collaboration

THANK – YOU!

Date post:	27-Dec-2015
Category:	Documents
Upload:	theresa-stevenson
View:	219 times
Download:	1 times

Page 1 Software Engineering Institute Carnegie Mellon University Defense Acquisition University...

Documents