NPS-SEA-SEMP-excerpts

8/7/2019 NPS-SEA-SEMP-excerpts

1/51

II. SYSTEMS ENGINEERING METHODOLOGYA. OVERVIEW

The conception, design, and manufacture of a complex system demands a

disciplined process through which such a system transitions from an idea to a physical

reality. Any system, whether it is complex or simple, can be defined as:

an assemblage or combination of elements or parts forming aunitary whole, such as a river system or transportation system; any

assemblage or set of correlated members, such as a system of currency; anordered and comprehensive assemblage of facts, principles, or doctrines in

a particular field of knowledge or thought, such as a system of philosophy;a coordinated body of methods or a complex scheme or plan of procedure,such as a system of organization and management; any regular or special

method of plan of procedure, such as a system of marking, numbering, ormeasuring (Blanchard and Fabrycky, 1998, 1).

But systems are more than a group of components assembled to form a unitary

whole. Systems, through the interaction of their elements, have emergent properties

that arise only through the precise way in which their elements are combined. These

emergent properties are greater than the sum of the individual capabilities of the

elements; they define the system capabilities that either effectively or ineffectively meet

the stakeholders need. Indeed, systems are found in all realms and are analyzed and

defined in all academic disciplines. The principles of Systems Engineering (SE)

methodology, which govern the management, development, and manufacture of systems,

can be applied in all fields. In particular we are interested in the management,

development, and manufacture of technical, physical systems designed for military

application.

A Systems Engineering and Analysis (SEA) team was organized through the

Wayne E. Meyer Institute of Systems Engineering (WEMISE) at the Naval Postgraduate

School (NPS) to conduct a study on the future of expeditionary warfare. An overarching

SE methodology was crafted in order to guide the team through the process of

engineering an architecture and overarching set of system requirements for a system of


2/51

systems (SOS) to conduct expeditionary operations in littoral regions, exploring

interfaces and system interactions, and comparing Current, Planned, and Conceptual

architectures against these requirements. The mission of any SE methodology, according

to the International Council on Systems Engineering (INCOSE), is to assure the fully

integrated development and realization of products which meet stakeholders

expectations with cost, schedule, and [performance] constraints (INCOSE and American

Institute of Aeronautics and Astronautics (AIAA), 1997, 3). The stakeholder, in this

case, is the Deputy Chief of Naval Operations for Warfare Requirements and Programs,

OPNAV N7 - the originator of the request for this study. The SE methodology provided

a structured process for developing and integrating the overarching set of requirements

and Conceptual architecture for the Integrated ExWar Project.

No two projects are completely alike. Applying a heuristic procedure to the

development of an SE methodology implies that such a methodology must be tailored to

the specific project to which it is to be applied. Tailoring an SE methodology to fit the

needs of the project is perfectly acceptable provided the integrity of the process is

maintained (INCOSE and AIAA, 1997, 4). For example, some projects, such as research

and technology or the in-house studies of this kind, often only need to have the

stakeholder requirements defined and validated with limited follow-up activities to ensure

the integrity of requirements application (INCOSE and AIAA, 1997, 4).The SEA team had undertaken The Integrated ExWar Project as an integrated

team that included personnel from three different military services (Army, Navy, and Air

Force), with a wide range of operational experiences, and different nationalities

(Singapore and the United States). The SEA team concept strives to achieve the same

synergies of talent that exist on DOD Integrated Product Process Development teams.

Teams and similar collaborative efforts, as management experts Drs. Frank LaFasto and

Carl Larson point out, are an excellent way to grapple with large complex problems

(Lafasto and Larson, 2001, xix). Our team utilized an SE methodology to ensure the

process was defined and adhered to by the team, to identify and resolve conflicts, and to

verify that requirements developed by the team met stakeholder expectations (INCOSE

and AIAA 1997, 4). As pointed out by INCOSE, new and complex projects typically

need robust Systems Engineering to succeed, but, in all cases, the methods for applying


3/51

the Systems Engineering process must be adapted to project and team needs (INCOSE

and AIAA, 1997, 4).

1. Definition of Systems Engineering

There is no commonly accepted definition of SE given that the field is still

relatively new. Nevertheless, our preferred definition, which comes from the Defense

Systems Management College (DSMC), is as follows:

The application of scientific and engineering efforts to (a)

transform an operational need into a description of system performanceparameters and a system configuration through the use of an iterative

process of definition, synthesis, analysis, design, test, and evaluation; (b)integrate related technical parameters and ensure compatibility of allphysical, functional, and program interfaces in a manner that optimizes the

total system definition and design; and (c) integrate reliability,maintainability, safety, survivability, human engineering, and other such

factors into the total engineering effort to meet cost, schedule,supportability, and technical performance objectives. (DSMC, 1990, 12).

2. Definition of Systems Analysis

An essential technical activity supporting any Systems Engineering methodology

is Systems Analysis (SA). Charles Calvano (Calvano, 2002a, 4), commented that

according to the Random House Dictionary of the English Language, analysis is the

process of separation into components as a method of studying the nature of something or

of determining its essential features and their relations. Therefore, SA, as it is utilized in

SE, is the process of decomposing a system into its component parts for the purposes of

study, evaluation, and/or generating requirements. At the conceptual stage, SA is often

referred to functional decomposition. When a conceptual system is decomposed into

key functions it can be further analyzed and broken down into sub-functions until it is

possible to describe and define various aspects of the conceptual system in greater detail.

The information obtained from SA is then synthesized, i.e., the component functions and

sub-functions are then reassembled into a more well-defined system set of requirements


4/51

and the SE process is able to move forward. The process of decomposing systems into

smaller parts and then synthesizing is illustrated graphically in Figure II-1.

Requirements

Analysis

FunctionalAnalysis/Allocation

Synthesis

Systems Analysis &

Control (Balance)

Requirements Loop

Design

Loop

Verification

Process

Inputs

Process

Outputs

Systems Engineering Methodology

Figure II-1: Graphical Illustration of SE Methodology(Source: MN 3331 School of Business, 2000, 4)

3. Top Down Analysis

SE methodology is based on a Top Down process that guides the engineer from

mission need and concept definition to a design solution. The task of decomposing a

conceptual system into its functional characteristics was described earlier in the definition

of SA. Functional decomposition is the primary task of Top Down analysis.

As described by professors Blanchard and Fabrycky, there are two main

characteristics of Top Down analysis. First, the process is applicable to the system as a

whole or to any part of the system. Repeated application of this process will result in

partitioning of the system into smaller and smaller functions until all that is left are the

basic elements of the system. Second, the process is self-consistent (Blanchard and

Fabrycky, 1998, 28). The properties of the system itself must be reproduced when the


5/51

properties of smaller functions, sub-functions, and basic elements are synthesized to form

the whole. A critical aspect of the Top Down process is that the systems engineer must

abstract from the particular case to the generic case, and represent the generic case by

several interacting functional elements (Blanchard and Fabrycky, 1998, 28). A

particular functional element, identified through functional decomposition, can be

associated with a whole class of systems. A class, in this case, is a set of systems that

share a common structure and a common behavior; it comes into existence in order to

help define problems and communicate solutions. Usually, only a few key functions are

needed to represent a system assigned to a particular class. Identifying these functions is

the basic starting point that allows the systems engineer to engage in system design

before physical manifestations have been defined (Blanchard and Fabrycky, 1998, 28).

Top Down analysis was incorporated into the SEA teams SE methodology within the

context of an SOS approach. Top Down analysis enabled the SEA team to identify the

functions associated with the component systems of the SOS.

4. Bottom-Up Synthesis

The Top Down analysis of SE methodology contrasts sharply with Bottom Up

synthesis where the integrator or design engineer starts out with a defined set of realelements (systems in the case of an SOS) and synthesizes a system (or SOS) out of

members from the set (Blanchard and Fabrycky, 1998, 28). Traditional engineering

design processes have relied on methods that employ Bottom-Up synthesis to create a

product or system. The Bottom Up method of designing systems starting with known

elements is iterative; often the functional need will not be met on the first attempt unless

the system is simple. More complex systems require repeated attempts and tweaks in

order for a Bottom Up approach to deliver a system capable of satisfying the

stakeholders need and operating within required performance parameters. Ultimately, a

combination of system complexity and the designers experience and creativity are what

determine how many Bottom Up attempts are required to get the final product thats

needed.


6/51

B. SYSTEM OF SYSTEMS APPROACH

The initial objective of Integrated ExWar Project, according to OPNAV N7, was

to explore design concepts for future Expeditionary Warfare systems using a system of

systems (SOS) approach (McGinn, 2002, 1). Little exists in the way of a definition of a

SOS. Our structural system definition described earlier includes elements, relationships,

and emergent properties. The elements that comprise a SOS are individual systems.

These systems, by definition, fulfill purposes in their own right and can continue to do so

even if removed from the overall SOS. One way to describe the relationship among the

individual systems within a SOS is each elemental system has managerial independence

from the others (Calvano, 2002b, 6). In other words the elemental systems can be

managed, at least in part, for their own purposes rather than the purposes of the whole

SOS. The elemental systems are brought together only as needed. Another way to

describe the relationship among the individual systems within an SOS is that each

elemental system can, and often does, have geographical distribution (Calvano, 2002b,

6). Dispersion of elemental systems can be quite large and, as a result, physical linkages

that would normally be necessary in individual systems are not necessary in an SOS.

Information exchange between the elemental systems within an SOS can suffice as the

defining linkage. An SOS performs functions that do not reside in any constituentsystem. Thus the emergent property or properties that, in part, define individual systems

are present in an SOS (Calvano, 2002b, 7). Finally, a unique attribute of an SOS is that it

is never fully formed or complete. The development of an SOS occurs over time;

structure, function, and purpose are added, refined, or removed as circumstances change

(Calvano, 2002b, 7). Scott Selberg of Agilent Technologies provides a more concise

definition of an SOS, A system of systems is a collection of independently useful

systems which have been assembled to achieve further emergent properties (Calvano,

2002b, 13).

The SEA teams task was to explore design concepts for expeditionary warfare

using an SOS approach. The SEA teams SE methodology, therefore, had to account for

the differences between a system and a SOS. Tables II-1 and II-2 show how SE


7/51

principles, employed in the design of a military system, relate to the design a military

SOS.

SYSTEM SYSTEM OF SYSTEMS

Configuration known in development Configuration not known until time of usePlanned and budgeted for Budget used for coordination and process

definition

DOD organized to acquire DOD not organized to acquire

Requirements state purpose of the system,

not the purpose of the components

Requirements state the purpose of the

system(s) and components

Program manager (PM) exists PM role may not exist

Common objective through singlemanagement of resources

Common objective through consensus orcompromise

Table II-1: System Versus SOS Comparison Using DOD SE Principles(Source: Calvano, 2002b)

SE Principle Level of Difficulty for SOS Application

Know problem, know customer Medium

Establish and manage requirements High

Identify, assess alternatives, and convergeon a solution

Medium

Maintain system integrity High

Manage to a plan HighVerify and validate requirements and

solution performanceHigh

Table II-2: DOD SE Principles as Applied to an SOS

(Source: Calvano, 2002b)

A military SOS design solution must balance operational, technical, political, and

economic considerations within cost, schedule, and performance constraints (Calvano,

2002b, 14). The SEA teams SE methodology, as applied to an SOS expeditionary

warfare design solution, had to emphasize communication interfaces because in an SOS

physical linkages are often not as important as the soft linkage of information

exchange. In light of the SOS approach, the proper emphasis had to be placed on the

understanding of key component systems because, unless these component systems


8/51

interfaces were effectively addressed and integrated, these systems would be unable or

unwilling to interact (Calvano, 2002b, 17). The Integrated Expeditionary Warfare

(ExWar) Projects SE methodology had to ensure that the SOS design solution requested

by the stakeholder would not break down due to the failure to address the interfaces.

1. SE Methodology for an SOS Approach

According to professors Benjamin S. Blanchard and Wolter J. Fabrycky of the

Virginia Polytechnic Institute and State University, there are two main differences

between the Top Down and Bottom Up processes. First, with Top Down analysis, the

design process ends with the system elements as functional entitiesthe realization of

physical elements is not guaranteed whereas, in the case of Bottom Up synthesis,

physical realizability in terms of known elements is assured (Blanchard and Fabrycky,

1998, 28). Second, in the Top Down approach, the requirements are always satisfied

through every step of the design process because it is an inherent part of the

methodology, whereas in the Bottom Up approach the methodology provides no

assurance that this will occur (Blanchard and Fabrycky, 1998, 28). These important

lessons provided sufficient reasons to combine the two approaches in the SEA teams SE

methodology.The Top Down analysis ensured that the SEA team was able to create a set of

overarching requirements for an expeditionary warfare SOS. The Bottom Up synthesis

provided the SEA team a process through which Current and Planned force structure

architectures could be studied and compared to the overarching requirements identified in

the Top Down analysis. The mismatches, or holes, that were found as a result of the

comparison of the two approaches were then translated into system-level Initial

Requirements Documents that called on the Aerospace Design (Aero), TSSE, and Space

Operations design teams to engineer system-level solutions for the Conceptual

architecture. As Top Down analysis and Bottom Up synthesis occurred, feedback in the

requirements and design loops (Fig. II-1) and verification of the requirements enabled the

SEA team to update the overarching requirements document as necessary. Each phase of

the SE process would bring another iteration of the requirements loop. Furthermore,


9/51

interaction between the SEA team and the design teams and academic groups across the

NPS campus would bring still more feedback within the requirements and design loops

and more updates to the overarching requirements. Quality controls, such as storyboards

and electronic shared drives, were in place to ensure that all changes and updates to the

SOS-level overarching requirements did not conflict with the derived need of the

stakeholder. If traceability from the smallest component all the way up to the SOS

derived need could not be achieved, errors would occur and quality could not be

maintained. As the SEA team performed increasingly detailed analysis, new information

was passed to the pertinent design teams and academic groups initiating new iterations in

the design loop.

C. THE SYSTEMS ENGINEERING PROCESS

The SEA team developed an SE methodology that enabled it to undertake the

Integrated ExWar Project and produce results that met the need of OPNAV N7. This

methodology governed a process that was comprised of three phases: (a) Conceptual

Design; (b) Preliminary Design; and (c) Detail Design and Development (Detail design,

as used here, means design of the details of the concept and is not used in the traditional

sense of producing production drawings and similar materials). The Integrated ExWarSE process is based on the SE process developed by Professors Blanchard and Fabrycky.

1. Conceptual Design, Phase 1A: Identify the Need

In any design development process one needs to ask basic questions like: What

products do we wish were available?; What is difficult with the current product we use?;

and Why does it not do something we want it to? (Otto and Wood, 2001, 17). The

answers to these questions are visions for a new design; forming a vision helps the design

team to analyze and understand what the stakeholder wants the new product to do.

Although the task of identifying the need seems to be basic and obvious, defining the

problem is the most difficult part of the SE process (Blanchard and Fabrycky, 1998, 46),


10/51

and, as has been stated so many times, all the serious mistakes are made in the first day

(Maier and Rechtin, 2002, 270). Getting this part right is of paramount importance.

The SEA team initiated this step upon receiving direction from the stakeholder in

the form of a memorandum from Vice Admiral Dennis McGinn, Deputy Chief of Naval

Operations for Warfare Requirements and Programs (OPNAV N7), dated 12 April 2002.

Next the SEA team, conscious of the questions outlined above, conducted a focused

study of germane Navy and Marine Corps operational concept papers and the Current and

Planned force structure architectures for expeditionary warfare. The results of this study,

and interaction with the Director, Expeditionary Warfare Division, N75, enabled the SEA

team to derive and define the need that serves as the basis for the Integrated ExWar

Project.

a. Integrated ExWar Project Derived Need

The Navy and Marine Corps need an ExWar Force that can accomplish

Operational Maneuver From the Sea (OMFTS), (Headquarters, USMC, 1996), STOM,

and Sea Basing through upgraded capabilities in the areas of amphibious lift, firepower,

aviation support, Information Operations, force protection, Command, Control,

Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR),and logistics.

2. Conceptual Design, Phase 1B: Management Plan

The next step in Phase 1 was to develop a management plan for the SE process.

A management plan clearly defines exactly how the SE methodology will affect the

overall project and translates the SE methodology into a plan of action and milestones.

The following items describe the outcomes of the process of developing a management

plan:


11/51

a. Define the Mission

A mission provides the overall direction for the team to undertake a complex

assignment in order to meet the need of the stakeholder. A clearly defined mission

statement provided focus for the SEA team. It answered the question, What is it we are

trying to achieve? when things got off track. Our mission statement is:

To engineer an architecture and overarching set of system requirementsfor a system of systems to conduct expeditionary operations in littoralregions, exploring interfaces and system interactions, and comparing

Current, Planned, and Conceptual architectures against these requirements.

b. Identify the Purpose and Then Scope the Problem

It is not enough to define whatis to be achieved without answering why it is to be

achieved. The memorandum from the Deputy Chief of Naval Operations for Warfare

Requirements and Programs dated 12 April 2002 clearly defined the purpose of the

Integrated ExWar Project:

The value added is expected to be a better understanding of theinterfaces and synergies among the ships, aircraft, and systems being

developed now, along with the necessary excursions (OPNAV N7

2002, 1).

The scope of the project includes not only the mission, but any other outlying

issues or excursions that are important to the stakeholder. The excursions mentioned by

the stakeholder for the Integrated ExWar Project were: (1) High Speed Vehicle (HSV)

types of high-speed platforms; (2) new Sea Basing options for logistics, command

facilities, and support of sustained operations ashore; and (3) new options for the

command and control of forces ashore (OPNAV N7, 2002, 1). Specific stakeholder

interests pertaining to these excursions included: (1) the Effects of Speed of platforms on

both logistics and warfighting; (2) the impact of a Reduced Footprint Ashore; (3) the

possibilities for weapon and sensor Modularity and missionizing of ships; and (4)

discovering opportunities for Reduced Manning of systems.


12/51

c. Assigning Responsibilities and Normalizing OrganizationalBehavior

The specifics of team and design organization management and the allocation of

responsibilities were all thoroughly discussed at the start of the SE process. Some had tobe modified as circumstances changed. A team leader (U.S.) and deputy team leader

(Singapore) for the SEA team were chosen. Meeting times and dates were established,

and expectations for quality of work and division of labor were defined. A decision-

making process involving group consensus was implemented. If consensus could not be

achieved, majority rule would be invoked. Initially the team worked together to get

preliminary aspects of the project accomplished. Sometimes, however, ad-hoc teams

were formed to accomplish special, short-term missions such as writing an initial

Concept of Operations (CONOPS) for the Conceptual architecture and Initial

Requirements Documents (IRD) for the design teams. Eventually, as the project work

grew more complex, permanent sub-teams with sub-team leaders were established to

accomplish analysis and modeling. The SEA team leader interfaced with the other design

team leaders; informal agreements were drawn up to govern the relationship between the

SEA team, subsidiary design teams, and academic groups that were participating in the

Integrated ExWar Project. Three faculty advisors - an academic advisor, a technical

advisor, and a project advisor - were appointed to oversee various aspects of the teams

efforts and ensure the overall project moved forward.

d. Choose the Tools

Section 1, Chapter III of this report identifies the tools that were used to

accomplish this project. The Functional Flow Block Diagram (FFBD) and Integrated

Definition Language (IDEF) tools were the central tools used for requirements analysis.

Various Operations Analysis techniques and the EXTENDTM modeling software were the

major tools used later on in the project for architecting and evaluation. Many of the tools

mentioned in Section 1, Chapter III were expensive to acquire, time consuming to learn

and operate, and required a lot of lead-time to obtain. It is a good rule of thumb to


13/51

carefully consider which tools will be used well in advance because of their critical

importance to the successful outcome of the project.

e. Develop a Plan of Action and Milestones

By identifying the ultimate deadline (the NPS graduation date for the team), the

SEA team worked its way backward and chose sensible milestone dates for critical areas

of the project. The overall plan of action and milestones then drove a more detailed

schedule that governed specific pieces of the project. The detailed schedule often had to

be modified as circumstances changed. Figure II-2 illustrates the overarching plan of

action and milestones.

Plan of Action and MilestonesPlan of Action and MilestonesSpring Qtr Summer Qtr Fall Qtr

AeroAero

ReportWriting

andTurnover

4 weeks

Space OpsSpace Ops

Design

Requirements

Design

Requirements

Generation

Generation

NPSNPS

ThesisThesis

IPR Student IPR Fix ReportConfiguration

AnalysisComplete

July 25 Sep 10 Nov 1 Nov 15

SEISEI

ModelingModeling

andand

AnalysisAnalysis

C4IC4I

Tactical AnalysisTactical Analysis

TSSETSSE

Figure II-2: Plan of Action and Milestones

(Source: SEA Team, 2002, 7)


14/51

3. Conceptual Design, Phase 1C: Defining the Capabilities Required

According to Professors Blanchard and Fabrycky, a requirement describes the

whats not the hows in terms of specific hardware, software, facilities, people, data,

etc. The resources supporting the hows will ultimately evolve from the functional

analysis and allocation process. The requirements must be complete and fully describe

the users need (Blanchard and Fabrycky 1998, 49). Derek Hatley, a requirements

engineer, explains further that, system requirements are a technology-independent

model of the problem the system is to solve (Hatley, Hruschka, and Pirbhai, 2000, 49).

In order for the SEA team to develop a Conceptual architecture as a design solution for

expeditionary warfare, a thorough requirements analysis had to take place.

Requirements analysis starts with a need and ends with an initial definition of a

system in functional terms. This process is iterative. Requirements analysis was

repeated again and again until a clearly defined architecture emerged with performance

specifications that enabled physical components to be designed and built. Requirements

analysis occurred during every phase of the SE process. In the Conceptual Development

Phase, requirements analysis produced the overarching SOS-level requirements that

became the starting point for further functional decomposition and analysis in the next

phase.Before commencing functional decomposition, SA methods were employed in

order to broaden the SEA teams understanding of the context in which an expeditionary

warfare SOS might operate. The analysis sub-team within the SEA team undertook a

thorough review of the hierarchy of governing documents describing expeditionary

warfare. A threat analysis was conducted in order to predict and define the environment

in which the ExWar Force would operate. Scenarios were developed in order to describe

the types of operations the ExWar Force would be expected to undertake given the

operational concepts and emerging threats. The SEA team, working with a Joint

Campaign Analysis class in the Operations Research Department at NPS, developed

more detailed operational timelines that would impact the ExWar Force. In addition, the

SEA team developed a Concept of Operations for the Integrated ExWar Project that


15/51

derived a set of high-level functions and implied capabilities for the ExWar Force. These

are all further described in Section II, Chapters IVVII.

Finally, the SEA team as whole began the daunting task of functional

decomposition of the expeditionary warfare SOS. Functional Flow Block Diagram

(FFBD) and Integrated Definition Language (IDEF) techniques, described further in

Section 1, Chapter III, were used in order to develop an initial overarching set of SOS-

level requirements. The actual overarching requirements are described further in Section

2, Chapter VIII.

4. Preliminary Design, Phase 2A: Identifying the Capabilities Available

Most of the Bottom Up work done on the Current and Planned architectures

occurred during this phase. For more information on the Current and Planned

architectures, read Section 3, Chapters IX and X. The SEA analysis sub-team explored

the capabilities of the ships, aircraft, weapons, and transportation devices employed in

these force structures. The next step was to identify mismatches, or holes, between the

capabilities that were available, or would be available assuming the planned programs

were fielded, and the capabilities that were required according to the Integrated ExWar

Projects CONOPS and overarching SOS requirements document. Certain holes werethen translated into Initial Requirements Documents (IRD) that were passed on to design

teams like TSSE, Aero, and Space Systems so system-level platforms could be designed

to fill these holes. The word initial was used in order to stress the tentative nature of

these requirements documents. Indeed, further iteration and interaction between teams

occurred in order to refine these design concepts. The design teams employed self-

tailored SE methodologies at the systems level in order to accomplish their assigned

tasks. From the point of view of the design teams, the SEA team was the stakeholder.

5. Preliminary Design, Phase 2B: Developing the Conceptual

Architecture

The system architecture model is a technology-dependent model of the solution

to the problem: It represents the how (Hatley, Hruschka, and Pirbhai, 2000, 49), and it


16/51

describes the physical structure of the system or SOS. Systems architecting requires a

great deal of creativity and artistic skill. Since every project is essentially different, there

are no pre-determined mathematical formulas that can be used to precisely predict the

right architectural solution to the problem. The SEA teams architecting procedure

combined heuristics, modeling, and interactions with the design teams and other

academic groups on the NPS campus. The overall process of architecting yielded more

requirements updatesreemphasizing the iterative nature of the overall SE methodology

and process illustrated in Figure II-1. In fact, as a well-known systems architect, Dr.

Eberhardt Rechtin points out, Systems requirements are an output of architecting, not

really an input (Maier and Rechtin, 2002, 18). While this runs contrary to the accepted

convention, it is often the case that final requirements do not emerge until systems

architecting has run its course. It is in this phase the Top Down analysis and Bottom Up

synthesis converged as illustrated in Figure II-3.

ExWarExWar Study ApproachStudy Approach

Top Down AnalysisTop Down Analysis

(Integral of Capabilities(Integral of Capabilities

Required)Required)

Functional Flow AnalysisFunctional Flow Analysis

Integrated Definition LanguageIntegrated Definition Language

Integrated Future CONOPSIntegrated Future CONOPS

ScenariosScenarios

Bottom Up AnalysisBottom Up Analysis

(Integral of Capabilities(Integral of CapabilitiesAvailable)Available)

Conceptual DesignsConceptual Designs

Dynamic System ModelDynamic System Model

Campaign AnalysisCampaign Analysis

Paper StudiesPaper Studies

Current and planned systemsCurrent and planned systems

Technology assessmentsTechnology assessments

Current CONOPSCurrent CONOPS

IntegrationIntegration

(Identification of gaps(Identification of gaps

and opportunities)and opportunities)

Figure II-3: Integrating the Two SA Approaches(Source: SEA Team, 2002, 6)


17/51

a. Heuristics

According to Dr. Rechtin, a heuristic is a guideline for architecting, engineering,

or design - a natural language abstraction of experience (Maier and Rechtin, 2002, 294).

The art in architecting lies not in the wisdom of the heuristics, but in the wisdom of

knowing which heuristics apply, a priori, to the current project (Maier and Rechtin,

2002, 27). Here are some heuristics that applied to this project and SOS architecture:

Multitask Heuristics: (1) If anything can go wrong, it will (Maier and Rechtin,

2002, 269). (2) The first line of defense against complexity is simplicity of design (Maier

and Rechtin, 2002, 269). (3) Dont confuse the functioning of the parts for functioning of

the system (Maier and Rechtin, 2002, 269).

Scoping and Planning: (1) Success is defined by the beholder, not by the architect

(Maier and Rechtin, 2002, 270). (2) No complex system can be optimum to all parties

concerned, nor all functions optimized (Maier and Rechtin, 2002, 270). (3) Dont assume

that the original statement of the problem is the best or even the right one (Maier and

Rechtin, 2002, 271).

Modeling: (1) Modeling is a craft and at times an art (Maier and Rechtin, 2002,

272). (2) A model is not reality (Maier and Rechtin, 2002, 272). (3) Regarding intuition,

trust but verify (Maier and Rechtin, 2002, 273). (4) If you cant explain it in five

minutes, either you dont understand it or it doesnt work (Maier and Rechtin, 2002, 273).

Partitioning: (1) Do not slice through regions where high rates of information

exchange are required (Maier and Rechtin, 2002, 274). (2) Design the structure with

good bones (Maier and Rechtin, 2002, 274).

Integrating: (1) When confronted with a particularly difficult interface, try

changing its characterization (Maier and Rechtin, 2002, 275).


18/51

Assessing Performance: (1) A good design has benefits in more than one area

(Maier and Rechtin, 2002, 276). (2) If you think your design is perfect, its only because

you havent shown it to someone else (Maier and Rechtin, 2002, 276). The first quick-

look analyses are often wrong (Maier and Rechtin, 2002, 277).

b. Modeling

Modeling is the creation of abstractions or representations of the system or SOS.

Models are used to predict and analyze performance as well as serve as a means of

communication in describing how the requirements will be achieved. During

architectural development, paper modeling was used to develop and communicate

concepts for the SOS architecture. The early use of EXTENDTM involved this type of

modeling. Later on, as the model became more and more concrete and specific,

EXTENDTM was used to perform an evaluation of the Current, Planned and Conceptual

architectures. Other types of modeling tools used in architecting, such as ARENA,

EINSTein, and EXCEL, fleshed out smaller pieces of the SOS Conceptual architecture by

analyzing sub-functions and recommending design solutions for the overall SOS

Conceptual architecture. For more information on models, see Section 1, Chapter III.

c. Interaction with Design Teams

Interaction with the TSSE, Aero, and Space Operations design teams, as well as

the C4ISR and Joint Campaign Analysis classes, was critical to architecting a conceptual

force structure for the Integrated ExWar Project. The design teams provided physical

platforms that were integrated into the overall architectural structure. Control of this

integration process was done via requirements management. As trade-off studies and

system level analyses of alternatives were conducted, the interfaces between heavy-lift

aircraft and sea base capabilities were identified and the requirements for both platforms

were updated to ensure the two systems were interoperable. The same held true for the

design interfaces between the C4ISR architecture and the Space Operations conceptual

design for a low-Earth orbit satellite described in greater detail in Section 4, Chapter


19/51

XVII. There are countless other examples of critical interfaces being tracked and

managed by the SEA team through requirements management. As the physical pieces of

the SOS took their final forms under the influence of team interaction, the Conceptual

architecture was further and further refined.

6. Detail Design and Development, Phase 3

With an Integrated CONOPS in hand and a Conceptual architecture beginning to

take shape, the SEA team used SA, at a deeper level, to: (1) evaluate the Current,

Planned, and Conceptual architectures; and (2) address the stakeholders concerns

regarding project excursions. The design teams also refined their platforms and finalized

their conceptual designs as well. For more information on this years work on conceptual

designs as well as previous NPS work on conceptual designs related to this project, read

Section 4, Chapters XIV XVIII.

a. Evaluation of Architectures

The EXTENDTM model was the centerpiece of the evaluation of the Current,

Planned, and Conceptual architectures. This evaluation effort was analogous to theanalysis of alternatives usually undertaken in the DOD acquisition process at the

conceptual level. The types of comparisons and the use of modeling to quantify the

results are shown in Figure II-3. For more information of the results of this evaluation,

read Section 3, Chapter XIII.


20/51


21/51

III. SYSTEMS ENGINEERING METHODOLOGY

A. OVERVIEW

A system is a set of interrelated components working together toward a common

objective. The International Council on Systems Engineering (INCOSE) definesSystems Engineering as:

An interdisciplinary approach and means to enable the realization

of successful systems. It focuses on defining customer needs and

required functionality early in the development cycle, documentingrequirements, then proceeding with design synthesis and system

validation while considering the complete problem:

Operations

Performance

Test

Manufacturing

Cost & Schedule

Training & Support

Disposal

Systems Engineering integrates all the disciplines and specialty

groups into a team effort forming a structured development processthat proceeds from concept to production to operation.

Systems Engineering considers both the business and the technical

needs of all customers with the goal of providing a quality productthat meets the user needs.

This definition shows that the function of Systems Engineering is essentially to guide the

engineering and development of multidisciplinary systems. Nowhere is this more critical than in

the design and implementation of joint combat systems.

There are several processes that can be used for guidance in these efforts.

Systems Engineers have developed several formal methodologies for accomplishing this task,

many of which are tailored for specific uses. The common thread in each of these methodologies

is a basic framework that includes a structured method for defining the problem. Some methods

also include processes to generate alternative solutions, analyze the alternatives, and then select

III-1


22/51

the best alternative. This basic framework is appropriate for multidisciplinary engineering

systems such as those that address large-scale, complex military problems. The design

methodology, called the Systems Engineering and Management Process (SEMP), was introduced

as the methodology for use in this study. The SEMP is depicted in Figure III-1.

Environment

ProblemDefinition

Needs

Analysis

Value System

Design ImplementationPlanning for

Action

Assessment &

Control

Execution

Engineering

Design Problem

Design &AnalysisAlternatives

Generation

Modeling &Analysis Decision

MakingAlternative

Scoring

Decision

Cultur

al

Politi

cal

Histor

ical

Moral/Ethical

Economic

Technological


23/51


24/51

2. Stakeholder Analysis

The purpose of stakeholder analysis is to identify the people and/or organizations that are

relevant to the problem and to determine their needs, wants, and desires with respect to the

problem to be solved. These groups are referred as stakeholders because they have a

considerable stake or vested interest in the problem and its eventual solution. Typical

stakeholder classes include clients, sponsors, decision-makers, users and analysts.

The stakeholder analysis allows Systems Engineers to begin identifying critical

assumptions and constraints on the problem. These assumptions and constraints set the

boundaries that Systems Engineers have to work within to solve the problem. These boundaries

come from a variety of sources and may include assumptions ranging from strategic to tactical.

Resources such as time, personnel, and funding are the most typical constraints; however, there

may be physical, legal, environmental, social, and technological constraints to consider as well.

3. Functional Analysis

The primary purpose of functional analysis is to identify and decompose critical system

functions, and to organize them in such a way as to facilitate a better understanding of the system

functional requirements. In other words, it describes what the system must do, but not how it

will be implemented. Functions are purposeful actions of the system that involve the

transformation or alteration of material, energy, information, and/or other resources. A function

also implies some input that undergoes a transformation process to produce a desired output.

Functional analysis is a two-step process. The beginning of this process is

functional decomposition. The purpose of functional decomposition is to identify and

decompose the systems critical functions. System decomposition contains four elements:

system functions, system components, hierarchical structure, and system states.

System functions are purposeful actions of the system that involve the transformation or

alteration of material, energy, information, and/or other resources. This function implies some

input that undergoes a transformation process to produce a desired output. System components

can be structural (static elements of the system that do not change as the system performs its

transformation function), operating (dynamic elements that perform the processing), or flow

III-4


25/51

components (transformed elements that are changed by the system). The systems components,

or the system as a whole, may assume different quantitative and/or qualitative values that

describe the current state of the system. These values are variables used to describe the

components or to measure the system state. As the system performs its function, the values of

the state variables will change to reflect an instantaneous condition (or state) of the system. The

hierarchical structure is the physical and/or functional relationship between components.

The result of a functional decomposition is a list of functions and subfunctions required

of the proposed system. The most difficult part of the functional decomposition is avoiding the

tendency to develop solutions based on existing systems. Thinking in terms of existing systems

limits the range of possible solutions. The Systems Engineer needs to focus on the purpose of

the intended system and avoid preconceived solutions. After completing the

functional decomposition and development of a list of functions and subfunctions, the next step

of functional analysis is to organize this list in a meaningful way. One method of doing this is by

creating a functional hierarchy. This hierarchy, or tree, captures the results of the

functional decomposition by showing the top-level functions required of the system broken down

into subfunctions. Each of these functions and subfunctions in the hierarchy must be well

defined to ensure a common understanding. Figure III-3 shows a generic functional hierarchy.

III-5


26/51

Generic Functional Hierarchy

Subfunction 1.1

Subfunction 1.2.1 Subfunction 1.2.2

Subfunction 1.2

Function 1 Function 2

Subfunction 3.1

Function 3

System(Effective Need)

Figure III-3 Generic Functional Hierarchy

Another method of organizing the list of functions and sub functions from the functional

decomposition is a functional flow diagram. The functional flow diagrams purpose is to lay out

in a sequential manner the order in which functions are performed in a system using a flow chart.Figure III-4 is an example of a functional flow diagram for a fire request.

Figure III-4 Functional Flow Diagram

III-6


27/51

Functions are diagrammed in series and parallel to depict the relationship between

functions. As with a functional hierarchy, an ideal functional flow diagram is logical and helps

in the design process without implying particular solutions. This method of organizing the

system functions allows the systems engineer to identify critical interfaces between system

functions that may later be used to develop alternative subsystems that will function together as

an integrated system. Functional flow diagrams may identify functions that are repeated and

present opportunities to combine or reorder functions as appropriate.

Depending on the problem, either or both functional hierarchy or a function flow may be

used. Functional flow diagrams may be more appropriate for a system when the functions are

ordered or sequential. Those systems whose functions do not flow in a sequential manner are

better suited for a functional hierarchy. In some cases, both can be used.

The functional analysis results are used in the next phase of the SEMP, which is the

design and analysis phase. The design of alternative systems will depend on the system

functions identified in the functional analysis.

C. FUTURES ANALYSIS

The futures analysis purpose is to analyze the environment in which the system will be

operating. This phase requires making several projections and predictions about the future from

many different aspects. The primary objective is to identify the key variables that will shape the

future environment and ultimately drive the system and/or organizations that use the system.

These factors, or drivers, will aide in the design of a system better prepared to operate in the

future. As a result, the completed system should be robust enough to meet both the present and

future needs of the stakeholders and operate successfully in the present and in future

environments.

1. Value System Design

The value system designs primary purpose is to develop a value hierarchy that will be

used to evaluate potential alternative solutions and ultimately select the best of the proposed

alternatives. A value hierarchy is a pictorial representation of the structure of the functions,

objectives, and evaluation measures for a given system. It is developed from efforts completed

III-7


28/51

during the needs analysis and should be a reflection of the needs and objectives of the

stakeholders.

Development of the value hierarchy begins with the effective need statement developed

during the needs analysis. Major critical functions form the next layer, much like the

functional analysis. As with the functional analysis, functions and/or objectives are decomposed

into subfunctions. The primary difference between the value hierarchy and the

functional hierarchy is the identification of objectives for each bottom level subfunction. These

objectives should be specific and measurable. Evaluation measures are then developed for each

objective as a metric that can be used as a measure of how well a proposed alternative meets that

objective. Figure III-5 is a generic example of a value hierarchy.

Generic Value Hierarchy

Evaluation Measure

Objective 1.1.1

Evaluation Measure

Objective 1.1.2

Subfunction 1.1 Subfunction 1.2

Function 1 Function 2 Function 3

Effective Need

Figure III-5 Generic Value Hierarchy

As the value hierarchy is refined, it is important to note that the values and objectives

should reflect the stakeholders values. These values should be approved and accepted by the

client and then presented to the stakeholders before proceeding further. Ultimately, it is the

III-8


29/51

client that will use the value hierarchy to aid in any decisions regarding the best alternative

system that will be designed to solve their problem.

D. DESIGN AND ANALYSIS

The SEMPs design and analysis phase designs and proposes alternative solutions to the

problem identified in the problem definition phase and then analyzes the performance of these

proposed solutions. The two steps in this phase are alternatives generation and modeling and

analysis.

1. Alternatives Generation

Alternatives generation is the process of bringing system alternatives into being. It is the

creative mental process of producing concepts and ideas in order to solve problems. In theprevious steps of the SEMP, it was important to avoid introducing preconceived solutions into

the process. Since there is no single solution to most systems engineering problems, one of the

goals in this step is to avoid considering only known or traditional alternatives. Some complex

problems are best solved using non-traditional means, so the creation of those means should not

be influenced by traditional methods.

This process is creative, yet structured. Several alternatives will be created, as well as a

structured approach to selecting the best ones for analysis. Best is defined as those alternatives

that will satisfy the needs of the stakeholders using the resources available to the client. Several

alternatives may meet the stakeholders needs. The job of the Systems Engineers is to propose

alternatives, recommend a preferred alternative, qualify that recommendation, and allow the

client to choose which alternative to implement.

Approaches to generating alternatives vary, but each relies on the identification of critical

functions that that system must perform. Research and brainstorming are good methods to

develop alternative ways to perform each function and subfunction. Alternatives for each

function and/or subfunction can then be packaged as a complete system alternative. It is

important that each alternative be significantly different from one another. Each alternative

should offer the client a markedly different method to meet the effective need. Alternatives

III-9


30/51

should be detailed to allow sufficient means of comparison and to facilitate modeling efforts in

later steps. In general, alternatives will fall into four categories:

Do Nothing

Off the shelf

Adaptation

New and Unique

Using these four categories can help in the process of alternatives generation. It gives the

Systems Engineers a place to start and a method of organizing potential alternatives.

2. Modeling and Analysis

The modeling and analysis phases purpose is to predict or estimate the performance of

the proposed alternatives with respect to the evaluation measures developed in the value

hierarchy. The alternatives were developed with sufficient detail to provide a clear picture in

terms of system parameters and variables to allow accurate modeling and facilitate prediction of

performance based on those evaluation measures. The first step in the process is to select the

models that will be used to evaluate the proposed alternatives. The models, either existing or

developed, must be properly formulated, applied, and interpreted so that the results accurately

reflect the real systems characteristics.

Models come in three basic forms: physical, visual, and mathematical. Physical models

are simply scaled physical representations of an object or system. Visual models are graphical or

pictorial representations of an object or system. Mathematical models use symbols of math and

logic to represent the various components, subsystems, functions and their relationships in an

object or system.

Once modeling and analysis for each alternative is complete, the next step is to compile

and organize the data in a useful manner. The organization of the data should present all of theinformation necessary to analyze and compare each proposed alternative. This should serve as

the basis for presenting the information to the client in a format suitable for decision-making.

Ultimately, the data will be converted to a decision-making format that will be used to

recommend the best alternative to the client. The proper implementation of this phase is very

III-10


31/51

important as a significant error in modeling could lead to the wrong recommendation and

ultimately to the wrong decision.

E. DECISION MAKING

The purpose of the decision-making phase is to use the information from previous phases

to select the best proposed alternative, and present that alternative to the client as a

recommendation of the best method to meet their effective need. Once approved by the client,

the next phase of the SEMP can begin. The two steps in this phase are: alternative scoring and

the decision.

1. Alternative Scoring

The purpose of alternative scoring is to use a structured method to compare the results of

modeling dissimilar alternatives with respect to the evaluation measures developed in the value

systems design. Scores for each alternative are calculated using information obtained from

research and modeling efforts in the modeling and analysis phase. Scores are based on

performance in respect to each evaluation measure and the relative importance of those measures

as delineated in the value system design. This process involves constructing a utility relationship

for each evaluation measure and using that relationship to calculate a total score for each

alternative. The total score for each alternative reflects its aggregate performance with respect to

all of the evaluation measures. These scores are then used as a basis for making a

recommendation and ultimately driving the final decision. Generally, the alternative with the

highest score is the one recommended to the client.

2. Decision

This step of the SEMP represents the decision from the client based on the

recommendation from alternative scoring. The recommendation may be presented to the client

in person or in a written report. To aid in conveying the recommendation, performance data for

each alternative must be gathered and presented in a succinct manner. Matrices can be used for

comparisons and graphs can be used to depict the sensitivity of decision variables. All should be

focused to support the recommended alternative. The most important part of this phase is to

present the recommendation in a clear, convincing, and concise manner.

III-11


32/51

F. IMPLEMENTATION

Normally, this phase would begin once the client has made a decision. The construction

of the selected system is planned and executed. Construction entails nonrecurring engineering

efforts, prototypes, test and evaluation, and manufacturing and production. This step ultimately

solves the problem presented by the client. Although there are various steps in this phase, they

do not apply for a paper study. As this study is a paper study only, it would ideally end with the

presentation of the recommended system to the client, and the acceptance and approval of the

system by the client and the stakeholders.

G. SUMMARY

It should be noted that use of the SEMP will normally be tailored to the individual projectand that the phases of the SEMP are iterative in nature. For a given project, some steps may be

omitted and extra time may be spent on others. Some phases and/or steps may be repeated as

necessary to ensure that the requirements of that particular phase of the process are met and to

ensure that the solution to the engineering design problem best meets the needs of the client and

stakeholders. Most importantly, the SEMP as a whole is iterative, meaning that it too should be

repeated as necessary to readdress the system solution and how it meets the needs of the client.

The SEMP is integral to this studys approach to force protection of the Sea Base. It was

important to start with this process, as there were several supporting teams working a project that

was not clearly understood in the beginning. The SEMP allowed the SEA-4 Team to

methodically approach the problem to be solved and integrate the previous study and the efforts

of several supporting teams. Chapter IV will discuss the SEA-4 Teams use of the SEMP and

how it was tailored to meet the needs of this study.

III-12


33/51

ammunition (Class V) are examined since they make up 98% of the weight of daily

replenishment requirements24

for operations ashore.

1.4 Methodology

This section reviews the systematic approach SEA-6 uses to conduct its analysis

of Seabasing and JELo.

1.4.1 Systems Engineering

There are many systems engineering approaches and processes. A definition that

captures the essence of systems engineering originates from the International Council on

Systems Engineering (INCOSE). They define systems engineering as:

Systems Engineering is an interdisciplinary approach and

means to enable the realization of successful systems. It focuseson defining customer needs and required functionality early in the

development cycle, documenting requirements, then proceeding

with design synthesis and system validation while considering the

complete problem:

Operations

Performance

Test

Manufacturing

Cost and Schedule

Training and Support

Disposal

Systems Engineering integrates all the disciplines andspecialty groups into a team effort forming a structureddevelopment process that proceeds from concept to production to

operation. Systems Engineering considers both the business and

the technical needs of all customers with the goal of providing a

quality product that meets the user needs.25

This top-level definition of the systems engineering approach is useful in

understanding the overarching principles that guide the systems engineering process, but

11

24 Center for Naval Analysis, Project Culebra: Seabased Combat Service Support for Ship-to-Objective-

Maneuver, [CNA CRM 95-144], September 1995, p. 11.25 What is Systems Engineering, available from http://66.34.135.97/whatis.html;accessed on03 November 2004.


34/51

it is not a cookie-cutter approach readily applied in every project. Just as no two projects

are exactly alike, no two systems engineering methodologies are exactly alike. The

systems engineering approach serves as a guide to the systems engineer and acts as a

blueprint to frame a problem so validated tools or techniques can guide the design, test

and evaluation of the overall system.

1.4.2 Joint Capabilities Integration and Development System

SEA-6 uses the Department of Defense (DoD) Joint Capabilities Integration and

Development System (JCIDS) as its systems engineering blueprint to guide the analysis

of the Seabased and JELo problem. JCIDS is the current DoD systems engineering

framework approved by the Chairman of the Joint Chiefs of Staff to guide the services in

system development and acquisition.

The need for JCIDS stems from the traditionally inefficient and costly

service-oriented practice of stove-piped acquisition, where single-service system

solutions frequently result in a duplication of assets among the services. JCIDS inspires

more objective system analysis and joint war fighting needs prioritization. It seeks to

transform the services out of the stove-piped acquisition paradigm by providing a

methodical process to identify, describe, and prioritize capability gaps. In addition, the

JCIDS approach promotes the exhaustion of often over-looked nonmateriel solutions

prior to committing to costly materiel acquisition programs.

JCIDS encompasses a structured, four-step methodology that identifies capability

needs, capability gaps and approaches to provide capabilities within a specified

functional or operational area. The approach is based on national defense policy and is

centered on Joint Operating Concepts and current integrated architectures. The analysis

enables the development of integrated joint capabilities from a common understanding of

existing joint force doctrine, organization, training, materiel, leadership and education,

12


35/51


36/51

solving one or more of the capability gaps identified in the FNA phase. The outputs of

the FSA phase are potential solutions to fill the gaps identified in the FNA phase. This

phase also specifies a priority of solutions in that alternative architecture designs first

focus on nonmateriel solutions to narrow or close the capability gaps to prevent unneeded

and costly new materiel starts. Existing product improvements are the next priority, with

costly and time-consuming new materiel acquisition programs as a last resort.29

The final phase of the JCIDS analysis approach is the Post Independent Analysis.

In this phase, the sponsor considers the compiled information and analysis results to

determine which integrated DOTMLPF solution best addresses the joint capability gap in

the functional area.30

This final JCIDS phase is out-of-scope for the SEA-6 project and is

left to the project sponsors for their consideration.

1.4.3 SEA-6 Approach

The JCIDS framework satisfies both the classical systems engineering process, as

well as the unique DoD transformational need to improve interoperability and to exhaust

nonmateriel solutions prior to implementing unneeded, costly and time-consuming

materiel ones. The classical systems engineering process maps directly to the four-step

JCIDS process as depicted in Figure 1-3.

14

29 Ibid.30 Ibid.


37/51

FunctionalSolutions

Analysis

FunctionalNeeds

Analysis

Functional

AreaAnalysis

Post

Independent

Analysis

FunctionalSolutions

Analysis

FunctionalNeeds

Analysis

Functional

AreaAnalysis

Post

Independent

Analysis

Figure 1-3: Mapping the Classical Systems Engineering Process to the Four-Step JCIDS Process.

In the past, many SEA and DoD projects have focused on materiel acquisition

solutions and failed to explore the significant amount of trade space that the additional

nonmateriel analysis makes available. The recent DoD change in systems engineering

toward JCIDS analysis permits SEA-6 to explore the additional nonmateriel trade-space

and focus on both materiel and nonmateriel centric alternative solutions to fill capability

gaps. SEA-6 views the JCIDS approach as an extension of the classical systems

engineering process and one that is tailored toward enhancing joint military operations.

In the military environment, a materiel solution alone is insufficient to define an

architecture or to create a complete war fighting solution. Synchronization across the

DOTMLPF spectrum is required to provide a balanced, cost-effective, and reliable

war-fighting system. SEA-6 uses the JCIDS with the system engineering process

depicted in Figure 1-4 as a framework for the Seabasing and JELo study.

15


38/51

Operating

Concept

JCIDS Framework

Functional

Area

Analysis

Functional

Needs

Analysis

D O T M L P F

Functional Solutions Analysis

Alternative Architecture



Conclusions / Recommendations

Figure 1-4: Flowchart of the SEA-6 JCIDS Framework.

1.4.4 Program Management Plan

The first phase of the SEA-6 project is one of problem definition and organization

into a team-of-teams that focuses toward a common goal. Aiding SEA-6 in this endeavor

is the JELo Project Management Plan (PMP). The PMP defines the JELo tasking,

problem definition, scope, system boundaries, and initial program assumptions and

constraints. It further defines program deliverables, quality assurance, and acts as a risk

mitigation tool by which schedule risk may be evaluated against the budgeted work

breakdown structure.

An additional role of the PMP is to depict both the SEA-6 external and internal

team organization. The Seabasing JELo problem is complex and collaborative

partnerships with external research teams is essential for successful project completion.

A list of collaborative partnerships for the SEA-6 Seabasing JELo project is found in

Table 1-3.

16


39/51

External Partnership Location Level of Effort

Total Ship Systems Engineering(TSSE)

Naval Postgraduate School(NPS),

Monterey, CA

Design of an alternative solution High SpeedAssault Connector.

N703(CDR Mark Becker)

Pentagon, VA Responsible for the Seabasing TransformationRoadmap. Share ideas with SEA-6 concerningSea Base Operating Concept (OPSCON).

Parallel effort to determine the most effectivemix of Sea Base components, interfaces, andoperations. Main focus on major theater of warscenarios vice small-scale operations. UsingExtend to develop a Sea Base simulation.

N42(LCDR Futcher)

Crystal City, VA Share ideas with SEA-6 concerning theSea Base Logistics CONOPS.

Marine Corps Combat DevelopmentCommand (MCCDC)

Quantico, VA Supporting information on 2015 MarineExpeditionary Brigade componentsand operations.

Naval Research Advisory Committee

(NRAC)

Share preliminary findings concerning capability

gaps. Review of NRAC Seabasing study for theAssistant Secretary of the Navy for Research andDevelopment (ASN (RD&A)).

Naval Sea Systems Command(NAVSEA)

(Mr. Jeff Koleser)

Carderock, MD Parallel analysis of the Seabasing JELo problemwith specific focus on generating operationalrequirements for connector and transfer systems.

Share ideas and data concerning at-sea,skin-to-skin transfer mechanisms. UsingExtend to develop a Sea Base simulation.

Naval Sea Systems Command(NAVSEA)

(Mr. Steve Wynn)

Carderock, MD Supporting cost data and performancespecifications for the Rapid Strategic Lift Ship

(RSLS).

NSWC Pt. Hueneme

(Mr. Marvin Miller)

Pt. Hueneme, CA Supporting information on connected

replenishment and skin-to-skin transfer programsand technologies.

NDIA-Sea Viking 2004 War Game Quantico, VA Sea Viking 04 (SV04), a two-week U.S. Joint

Forces Command and Marine Corps experimentexamining how to best project joint force power

ashore relying heavily on a joint Sea Base.Center for Naval Analysis (CNA) Maritime Prepositioning Force (Future) (MPF(F)

Analysis of Alternatives Study.

Operations Research DepartmentWar Game

(LTC Saverio Manago)

NPS, Monterey, CA Participation to gain a different perspective onthe performance of the 2015 Baseline

Architecture based on man-in-the-loopsimulation.

Air Force Institute of Technology(AFIT)

Dayton, OH SEA-6 generation of operational requirementsfor AFIT design of Joint Air Operations Center(JAOC).

TRADOC Analysis Center (TRAC)-Monterey

NPS, Monterey, CA Supporting information for Army BCT.

Operations Research Department

(LtCol Greg Mislick)

NPS, Monterey, CA Supporting information for cost estimation

and analysis.

Information Systems Department

(Prof. Rex Buddenberg)

NPS, Monterey, CA Supporting information for command and control

system composition and analysis.

Table 1-3: SEA-6 External Team Collaborative Partners.

External team relationships are important since they define the

chain-of-command and hierarchal relationships of the integrated and collaborative

17


40/51

partnership teams. The hierarchal relationship diagram governing the SEA-6 JELo

collaborative partnerships is depicted in Figure 1-5.

Figure 1-5: SEA-6 JELo Collaborative Partnership Hierarchal Chart.

Internal team organization and alignment is also a top priority in order to meet

milestone requirements. A literature review of prior studies and an analysis of

alternatives suggest that the most critical JELo functional areas contributing to capability

gaps correspond to the following functional subsystems:

1. Command and control.

2. Inventory and storage management.

3. Transfers at nodes between transportation connectors.

4. Point-to-point transportation connectors.

SEA-6 utilizes a competency-aligned organizational structure to build subject

matter expertise along these subsystem functional areas. This competency alignment

provides the backbone for the organization of the SEA-6 Team. Integrated product teams(IPTs) are developed to form a matrix organization to tackle specific tasks across the core

competency functional areas. This competency aligned organization is envisioned to

form the structure depicted in Figure 1-6. The command and control team serves as the

18


41/51

foundation for the JELo system and the other three functional teams form the support

pillars that enable JELo performance.

JELo

COMMAND & CONTROL

CONNECTORS

INVENTORY

&

STORAGE

CONNECTIONS

JELo

COMMAND & CONTROL

CONNECTORS

INVENTORY

&

STORAGE

CONNECTIONS

Figure 1-6: SEA-6 Project Team Internal Competency Alignment Organization.

1.4.5 Operating Concept

The first step in JCIDS is the Functional Area Analysis (FAA). However, before

the FAA can begin, one important question must be answered: What do we want the

system to accomplish? Answering this question requires research into published DoD

strategic guidance concerning military objectives (i.e., Quadrennial Defense Review,

Defense Planning Guidance, National Security Strategy of the United States, Joint Vision

2020, etc.). Other resources include the published Joint Operational Concepts (JOC), as

well as planned integrated architectures. Since much of the information for Seabasing

and JELo is ill defined for the 2025 time frame, SEA-6 authored an Operating Concept to

postulate its view of these operations in one coherent document. The SEA-6 Operating

Concept [Chapter 2] captures the general nature of operations independent from the level

of war and enables the generation of traceable high-level mission requirements in the

follow-on FAA.

1.4.6 Functional Area Analysis

The FAA [Chapter 3] answers the question, What needs to be done? It defines

the tasks, conditions, and standards for Seabasing and JELo and draws on the SEA-6

19


42/51

OPSCON to provide the strategic and operational construct for the problem. The output

of the FAA is a list of Seabased JELo tasks derived from the Universal Joint Task List

(UJTL) and a corresponding list of conditions and standards for each task. These tasks,

conditions and standards collectively form the operational requirements for the

Seabased JELo system. Design requirements from this analysis are furnished to the

Naval Postgraduate Schools Total Ship Systems Engineering curriculum for their

collaborative design effort. Additionally, these requirements are used in the design of the

2015 Baseline Architecture [Chapter 5].

1.4.7 Functional Needs Analysis

The primary purpose of the Functional Needs Analysis (FNA) [Chapters 4-11] is

to evaluate a current or planned integrated architecture against the requirements

generated in the FAA to identify any potential capability gaps. The FNA helps answer

the question, What capability gaps exist between what we have now and what

capabilities we will have with proposed future improvements? SEA-6 uses current

(2004) Programs of Record to establish a 2015 Baseline Architecture for Seabasing and

JELo operations. The SEA-6 Team uses a trade study, analysis of alternatives, and

literature review to select from existing systems and programs of record to form the

2015 Baseline Architecture.

SEA-6 then uses a simulation model to identify and quantify potential capability

gaps of the 2015 Baseline Architecture. The simulation model is designed as an

extensible, parameterized model to simulate not only the 2015 Baseline Architecture, but

also to accommodate the evaluation of alternative architecture designs. A design of

experiments is used to plan an efficient data collection effort. Operational requirements

generated in the FAA phase are used to formulate critical operational issues (COIs),

measures of effectiveness (MOEs), and measures of performance (MOPs) to evaluatesystem performance.

A SEA-6 threat-based capability study results in the development of an

operational scenario to judge system performance under realistic and expected

20


43/51

environmental and combative conditions. Scenario effects are captured in the input

variables of the simulation model to evaluate JELo system performance. Additionally, a

collaborative war game with the Naval Postgraduate Schools Operations Research

Department is conducted to gain a different perspective on the performance of the

2015 Baseline Architecture based on man-in-the-loop simulation. The cost of the

2015 Baseline Architecture is also estimated to provide a baseline for future cost-benefit

decisions concerning follow-on alternative architectures.

1.4.8 Functional Solution Analysis

The Functional Solution Analysis (FSA) [Chapters 12-13] is the third and final

phase of the SEA-6 systems engineering project. The FSA helps answer the question,

How can we close or reduce the capability gaps? The Seabasing and JELo system

capability gaps identified in the FNA are used as inputs for the design of alternative

architectures. The output of this phase includes designs of alternative architectures

intended to close or reduce the capability gaps previously identified in the FNA.

Additionally, the costs of these alternative architectures are estimated for comparison

with the 2015 Baseline Architecture.

SEA-6 divides into three competing design teams utilizing the DOTMLPF trade

space to design alternative architectures for the 2025 time frame. A sensitivity analysis

of the JELo simulation model parameters is conducted to gain insight into the Seabasing

and JELo system architecture component performance sensitivities enabling design teams

to focus toward specific, high-impact DOTMLPF changes. Alternative architectures are

also subjected to the same scenario in the simulation model as the 2015 baseline,

facilitating a side-by-side comparison. This pair-wise comparison allows identification

of any statistical or militarily significant performance gains and/or reductions in

capability gaps realized by the alternative architecture designs.

21


44/51

2

Deliverables: SEA-8 was specifically tasked to provide the following:

Informal Interim Progress Report (IPR): Four informal briefings wereconducted between June and October 2005, during which SEA-8 updated

the Meyer Institute faculty and staff on project progress with regard toresearch, analysis, modeling, management planning, and their cross-

campus partnership studies

A Formal Briefing: Conducted on 7 December 2005, this briefing of theentire project to senior Navy leadership and other invited visitors from the

military, academia, and the defense industry was held at NPS and included

a comprehensive study presentation conducted by SEA-8, an alternative

design brief conducted by TSSE, as well as several separate in-depth

briefings conducted by the individual SEA-8 teams covering their

individual research and conclusions

A Technical Report: The ultimate deliverable, consisting of the followingtechnical report delivered in December 2005, it covered all aspects of the

integrated study

1.3 SYSTEM ENGINEERING METHODOLOGY

Due to the scope and complexity of this particular subject, the security

requirements inherent in modern ASWalong with the requirement to keep this study

unclassified (UNCLAS)and the relatively short time available, SEA-8s focus was

bound to the following study plan:

Employ the Systems Engineering Design Process (SEDP),1 the SystemsApproach, as well as other systems engineering methodologies to analyze

alternative US ASW force structure options operating in a semiconstrained

sea-space 20 years in the future

Baseline the problem using a current force mix to analyze and compareseveral similar future force mixes expected to be in operation by 2025

1 Sage, Andrew R., James E. Armstrong, Introduction to Systems Engineering, John Wiley & Sons,

Inc., New York, 2000, p. 144.


45/51

3

Conduct a gap analysis between current force structure and the neededfuture force structure based on a comprehensive futures analysis to

identify potential holes in current defense planning

Make recommendations to Navy leadership to aide in futuredecision making

Throughout this process, various members of the NPS cross-campus community,

including the TSSE cohort, proposed improvements in planning and design of system

alternatives in an effort to ensure that the Navy meets forecasted future threats in

littoral ASW.

To conduct this study, SEA-8 formulated a mix of legacy and future platforms

and capabilities that could be modeled and tested to establish their capacity to meet theidentified future threats. Through this modeling and simulation process, SEA-8 hopes to

provide decision makers and stakeholders with a series of detailed performance schedules

and cost break-downs that will aid in future acquisition and employment strategy

decision making, as well as offering some potential alternatives for their consideration.

Team Structure: To facilitate this study, SEA-8 organized into functional teams

early on whose division was based on the identified critical aspects of the overall ASW

system architecture. The team breakdown was as follows:

Deployment Team Sensors Team (Prosecute) C4ISR Team (Command) Platform Design Team (PDT) (Modeling)Each team developed their respective Problem Definition, Needs Analysis

Alternatives Generation, and Modeling Analysis studies in accordance with the SEDP,

the Systems Approach, or some hybrid of each, appropriate to the specific functionalityof their respective areas of research, while at the same time, working together to share

specifications, requirements, objectives, and goals to ensure coordination and unity of

effort in providing solutions to the overall project problem statement.

The SEDP: There are many methods and processes available for conducting

systems engineering analysis, and, while no one method is best suited for every project,


46/51

4

SEA-8 made the decision early on to use the SEDP designed by Andrew Sage and

James Armstrong as the foundation of analysis in this integrated cross-campus study.

The SEDP focuses on practical analysis and includes many problem-solving

techniques and interpretation methods that can be applied throughout the life-cycle of a

complex system-of-systems (SoS) to gain understanding and insight into product

improvement and design.

Figure 1 depicts the SEDP process. SEA-8s specific study of future ASW

systems began with the Problem Definition Phase of the SEDP and followed that process

where appropriate through the Decision-Making Phase. Although the SEDP process

continues beyond the Decision-Making Phase, it was outside the scope of SEA-8s

tasking to conduct those portions of the process that cover Product Implementation.

Therefore, SEA-8 strove to analyze current and future ASW Command, Control,

Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR)

systems existing in the Navys program of record (POR), propose alternatives, and

inform potential decision makers of the most appropriate system architectures to achieve

success in littoral ASW in the 2025 time frame.

Environment

Problem

Definition

Needs

Analysis

Objectives

Analysis

Implementation

Planning for

Action

Assessment &

Control

Execution

Engineering Design

Problem

Design &

Analysis

Alternatives

Generation

Modeling &

Analysis

Decision

Making

Alternative

Scoring

Decision

Cultura

l

Politi

cal

Historic

al

Moral/Ethical

Economic

Technological

Assessment & Feedback

Descriptive Scenario

Current Status: What is?

Normative

Scenario

Desired End State:

What should be?

Environment

Problem

Definition

Needs

Analysis

Objectives

Analysis

Implementation

Planning for

Action

Assessment &

Control

Execution

Engineering Design

Problem

Design &

Analysis

Alternatives

Generation

Modeling &

Analysis

Decision

Making

Alternative

Scoring

Decision

Cultura

l

Politi

cal

Historic

al

Moral/Ethical

Economic

Technological

Assessment & Feedback

Descriptive Scenario

Current Status: What is?

Normative

Scenario

Desired End State:

What should be?

Figure 1: The SEDP

Problem Definition Phase Focused research and interaction with clients(sponsors, decision makers, and experts in the field), as well as early

contact with others involved with system development such as mechanical

engineers, aeronautical engineers, operators, and contractors, as


47/51

5

appropriate, to create a list of system requirements

NPS-SEA-SEMP-excerpts

Documents

Transcript of NPS-SEA-SEMP-excerpts