Lean Systems Engineering

Chapter_9_Cross-Cutting_Systems_Engineering_Methods_.pdf

Home >Engineering homework help >Lean Systems Engineering

INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, Fourth Edition. Edited by David D. Walden, Garry J. Roedler, Kevin J. Forsberg, R. Douglas Hamelin and Thomas M. Shortell. © 2015 John Wiley & Sons, Inc. Published 2015 by John Wiley & Sons, Inc.

180

The previous chapters provided a serial description of the systems engineering (SE) processes used across the system life cycle. This chapter provides insight into methods that cut across the SE processes, reflecting var ious aspects of the iterative and recursive nature of SE.

9.1 Modeling and SiMulation

Stakeholders of the SE life cycle have used models and simulations for some time both to check their own thinking and to communicate their concepts to others. The benefit is twofold: (i) models and simulations confirm the need for the systems and the anticipated system behaviors before proceeding with the development of an actual system, and (ii) models and simulations present a clear, coherent design to those who will develop, test, deploy, and evolve the system, thereby maximizing productivity and minimizing error. The ability to detect limitations and incompatibilities via system models and simulations early in a project helps avoid higher project cost and schedule overruns later in a project, especially during system oper ation. The value of modeling and simulation increases with the size, be it physical or complexity, of the system or system of systems (SoS) under development.

Early in the SE life cycle, the objective of modeling and simulation is to obtain information about the system before significant resources are committed to its design, development, construction, verification, or operation. To that end, modeling and simulation helps generate data in the domain of the analyst or reviewer, not available from existing sources, in a manner that is affordable and timely to support decision making. An adequate, accu rate, and timely model and simulation informs stake holders of the implications of their preferences, provides perspective for evaluating alternatives, and builds confidence in the capabilities the system will pro vide. They also help the development, deployment, and operational staffs comprehend the design requirements, appreciate imposed limits from technology and manage ment, and ensure an adequate degree of sustainability. Finally, adequate, accurate, and timely models and sim ulations help the organization and its suppliers provide the necessary and sufficient personnel, methods, tools, and infrastructure for system realization.

The long‐term benefits of modeling and simulation are commensurate with the gap between the extent, variety, and ambiguity of the problem and the compe tencies of downstream staffing. A relatively simple model of an intended system may be sufficient for a highly

CroSS‐Cutting SySteMS engineering MethodS

<i>INCOSE Systems Engineering Handbook : A Guide for System Life Cycle Processes and Activities</i>, Wiley, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/gwu/detail.action?docID=1895890. Created from gwu on 2019-12-03 08:57:39.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

ModEling And SiMulATion 181

competent staff, whereas a much more elaborate simulation may be necessary for a less competent staff, especially one faced with producing a novel, large‐scale system that is capable of autonomously coping with unpredict able mission situations. ultimately, the benefit of mod eling and simulation is proportional to the stakeholders’ perception of the timeliness, trustworthiness, and ease of use and maintenance of the model or simulation. Consequently, the planned resources anticipated to be spent in development, verification, validation, accredita tion, operation, and maintenance of the model must be consistent with the expected value of the information obtained through use of the model.

9.1.1 Models versus Simulations

The terms model and simulation are often mistakenly interchanged in discussions. Each term has its own specific meaning. The term “model” has many definitions but generally refers to an abstraction or representation of a system, entity, phenomenon, or process of interest (dod 5000.59, 2007). The many other definitions of model gen erally refer to a model as a representation of some entity in the physical world. The representations are intended to describe selected aspects of the entity, such as its geom etry, functions, or performance. in the context of SE, a model that represents a system and its environment is of particular importance to the systems engineer who must analyze, specify, design, and verify systems, as well as share information with other stakeholders. different types of models are used to represent systems for different mod eling purposes.

The term “simulation” is the implementation of a model (or models) in a specific environment that allows the model’s execution (or use) over time. in general, sim ulations provide a means for analyzing complex dynamic behavior of systems, software, hardware, people, and physical phenomena.

A computer simulation includes the analytical model that is represented in executable code, the input conditions and other input data, and the computing infrastructure. The computing infrastructure includes the computational engine needed to execute the model, as well as input and output devices. The great variety of approaches to com puter simulation is apparent from the choices that the designer of computer simulation must make.

in addition to representing the system and its environ ment, the simulation must provide efficient computational

methods for solving the equations. Simulations may be required to operate in real time, particularly if there is an operator in the loop. other simulations may be required to operate much faster than real time and perform thousands of simulation runs to provide statistically valid simulation results.

9.1.2 Purpose of Modeling

System models can be used for many purposes. one of the first principles of modeling is to clearly define the purpose of the model. Some of the purposes that models can serve throughout the system life cycle include:

• Characterizing an existing system: Many existing systems are poorly documented, and modeling the system can provide a concise way to capture the exist ing system architecture and design. This information can then be used to facilitate maintaining the system or to assess the system with the goal of improving it. This is analogous to creating an architectural model of an old building with overlays for electrical, plumb ing, and structure before proceeding to upgrade it to new standards to withstand earthquakes.

• Mission and system concept formulation and evalu- ation: Models can be applied early in the system life cycle to synthesize and evaluate alternative mission and system concepts. This includes clearly and unambiguously defining the system’s mission and the value it is expected to deliver to its benefi ciaries. Models can be used to explore a trade space by modeling alternative system designs and assess ing the impact of critical system parameters such as weight, speed, accuracy, reliability, and cost on the overall measures of merit. in addition to bounding the system design parameters, models can also be used to validate that the system requirements meet stakeholder needs before proceeding with later life cycle activities such as architecting and design.

• System architecture design and requirements flow- down: Models can be used to support architecting system solutions, as well as flow mission and system requirements down to system elements. different models may be required to address different aspects of the system design and respond to the broad range of system requirements. This may include models that specify functional, interface, performance, and

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

182 CroSS‐CuTTing SySTEMS EnginEEring METhodS

physical requirements, as well as other nonfunctional requirements such as reliability, maintainability, safety, and security.

• Support for systems integration and verification: Models can be used to support integration of the hardware and software elements into a system, as well as to support verification that the system satisfies its requirements. This often involves integrating lower‐level hardware and software design models with system‐level design models, which verify that system requirements are satisfied. Systems integration and verification may also include replacing selected hardware and design models with actual hardware and software products in order to incrementally verify that system requirements are satisfied. This is referred to as hardware‐in‐the‐loop testing and soft ware‐in‐the‐loop testing. Models can also be used to define the test cases and other aspects of the test program to assist in test planning and execution.

• Support for training: Models can be used to simu late various aspects of the system to help train users to interact with the system. users may be operators, maintainers, or other stakeholders. Models may be a basis for developing a simulator of the system with varying degrees of fidelity to represent user interaction in different usage scenarios.

• Knowledge capture and system design evolution: Models can provide an effective means for capturing knowledge about the system and retaining it as part of organizational knowledge. This knowledge, which can be reused and evolved, provides a basis for supporting the evolution of the system, such as changing system requirements in the face of emerg ing, relevant technologies, new applications, and new customers. Models can also enable the capture of families of products.

Models represent the essential characteristics of the system of interest (Soi), the environment in which the system operates, and the interactions with enabling and interfacing systems and operators. Models and simula tions can be used within most system life cycle processes, for example:

• Business or mission analysis—descriptive model of the problematic situation ensures the right problem(s) is being addressed.

• Requirements (stakeholder and system) definition— Enables justification of requirements and avoids over‐/underspecification.

• Architecture definition—Evaluate candidate options against selection criteria and enable active agents to discover the best architecture, including the integration to other systems.

• Design definition—obtain needed design data, adjust parameters for optimization, and update system model fidelity as actual data for system ele ments become available.

• Verification and validation—Simulate the system’s environment, evaluate verification and validation data (simulation uses observable data as inputs for computation of critical parameters that are not directly observable), and validate the fidelity of the simulation (false‐positives/false‐negatives).

• Operations—Simulations that reflect actual behavior and simulate operations in advance of execution for planning, validation, and operator training.

9.1.3 Model Scope

The model must be scoped to address its intended purpose. in particular, the types of models and associated modeling languages selected must support the specific needs to be met. For example, suppose models are con structed to support an aircraft’s development. A system architecture model may describe the interconnection among the airplane parts, a trajectory analysis model may analyze the airplane trajectory, and a fault tree anal ysis model may assess potential causes of airplane failure. For each type of model, the appropriate breadth, depth, and fidelity should be determined to address the model’s intended purpose.

The model breadth reflects the system requirements coverage in terms of the degree to which the model must address the functional, interface, performance, and physical requirements, as well as other nonfunc tional requirements. For an airplane functional model, the model breadth may be required to address some or all of the functional requirements to power up, take off, fly, land, power down, and maintain the aircraft’s environment.

The model’s depth indicates the coverage of system decompo sition from the system context down to the system elements. For the air transport SoS example shown in

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

ModEling And SiMulATion 183

Figure 2.2, a model’s scope may require it to define the system context, ranging from the aircraft, the control tower, and the physical environment down to the naviga tion system and its system elements, such as the inertial measurement unit, and perhaps down to the lower‐level parts of the inertial measurement unit.

The model’s fidelity indicates the level of detail the model must represent for any given part of the model. For example, a model that specifies the system interfaces may be fairly abstract and represent only the logical information content, such as aircraft status data; or it may be much more detailed to support higher‐fidelity information, such as the encoding of a message in terms of bits, bytes, and signal characteristics. Fidelity can also refer to the precision of a computational model, such as the time step required for a simulation.

9.1.4 types of Models and Simulations

There are many different types of models and simula tions to address different aspects of a system and differ ent types of systems. The specific type of model or simulation selected for a phase of the system’s life cycle depends on the intended use and particular characteris tics of the system that are of interest and the level of model accuracy required, in other words its “fitness for purpose.” generally, a specific model or simulation focuses on some subset of the total system characteristics, such as timing, process behavior, or various performance measures.

9.1.4.1 Types of Models “The image of the world around us, which we carry in our head, is just a model” (Forrester, 1961). Most systems start as a mental model that is elaborated and translated in several stages to form a final model or simulation product. A model maybe a mental image of selected concepts, and relationships between them, that can be translated to sketches, textual specifica tions, graphics/images, mock‐ups, scale models, proto types, or emulations. often, separate models are prepared for distinct viewpoints, such as functional, performance, reliability, survivability, operational availability, and cost.

it is useful to classify models to assist in selecting the right kind of model for the intended purpose and scope. Models can be classified in many different ways. The model taxonomy shown in Figure 9.1 is one such tax onomy and provides a useful classification for one in stance as an illustration and not necessarily providing an exhaustive set of model classes; other classes may exist:

• Physical mock‐ups—A model that represents an actual system, such as a model airplane or wind tunnel model, or a more abstract representation, such as a model that is often represented using a computer.

• Abstract models—An abstract model can have many different expressions to represent a system, entity, phenomena, or process, which vary in degrees of formalism. Therefore, the initial classification of models that distinguishes between informal models and formal models is noted, with this guidance focusing on formal models.

Physical mockup

Model

Abstract model

Formal model Informal model

Pictures Text documentsLogicalQuantitativeGeometric

Figure 9.1 Sample model taxonomy. reprinted with permission from Sandy Friedenthal. All other rights reserved.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

184 CroSS‐CuTTing SySTEMS EnginEEring METhodS

• Informal models—one can represent a system using a simple drawing tool or with words. however, unless there is clear agreement on the meaning of the terms in the less formal representations, there is a potential lack of precision and the possibility of ambiguity in the representation. While such informal representations can be useful, a model must meet certain expectations for it to be considered within the scope of modeling and simulation for SE.

• Formal models—Formal models can be further clas sified as geometric, quantitative (i.e., mathematical), and/or logical models. geometric model represents the geometric or spatial relationships of the system or entity. Quantitative models represent quantitative relationships (e.g., mathematical equations) about the system or entity that yield numerical results. logical models, also referred to as conceptual models, represent logical relationships about the system such as a whole–part relationship, an inter connection relationship between parts, or a prece dence relationship between activities, to name a few. The logical models are often depicted in graphs (nodes and arcs) or tables.

The following example illustrates the above taxonomy. An aircraft may be represented by a three‐dimensional geometric model that specifies the detailed geometry of the aircraft. The aircraft may also be represented by a quantitative model that represents its possible flight tra jectories in terms of its acceleration, speed, position, and orientation. The aircraft may be further represented by a logical model that describes the source and destination of signals across the aircraft or potential causes of air plane failure, such as how an engine failure can result in a loss of power and cause the airplane to lose altitude. it is apparent that many different models may be used to represent a Soi.

it should be noted that the semantics for each kind of formal model described above, including the geometric, quantitative, and logical models, can be defined using a mathematical formalism.

A system model is used to represent a system and its environment. A system model may comprise multiple views of the system to support planning, requirements, architecture, design, analysis, verification, and valida tion. System models can include a combination of geometric, quantitative, and logical models. They often span several modeling domains such as different systems

(e.g., thermal, power), different technology domains (e.g., hardware, software), and different characteristics (e.g., physical, performance). Each of these models must be integrated to ensure a consistent and cohesive system representation. As such, the system model must enable representation of general‐purpose system modeling con cepts such as behavior and structure that can be shared across modeling domains.

A. Wayne Wymore is credited with one of the early efforts to formally define a system model using a mathematical framework in A Mathematical Theory of Systems Engineering: The Elements (1967). Wymore established a rigorous mathematical framework for designing systems in a model‐based context.

Some examples of system models may include the following (from iSo/iEC/iEEE 15288):

• A functional model that captures the system functions and their functional interfaces

• A behavioral model that captures the overall behavior of the system functions

• A temporal model that captures the timing‐related aspects of the architecture

• A structural model that captures the system ele ments and their physical interfaces

• A mass model that captures the mass‐related aspects of the system

• A layout model that captures the absolute and relational spatial placements of the system elements

• A network model that captures the flow of resources among the applicable system functions or elements

9.1.4.2 Types of Simulations Simulations can be described under one or more of the following types:

• Physical simulations utilize physical models and aim to replicate a relatively small number of system attributes to a high degree of accuracy (fidelity). often, such simulations require physical models of specific environmental attributes with similar levels of fidelity. Such simulations are often costly to con struct and the limited number of system and envi ronment attributes restricts the range of questions that can be answered. This kind of simulation is used when cheaper computer‐based simulations cannot be constructed to answer questions. Examples of physical simulations are wind tunnels tests,

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

ModEling And SiMulATion 185

environmental tests, and mock‐ups that elucidate manufactur ing processes.

• Computer‐based simulations can be divided into subtypes based on models of computation (MoC), for example, discrete event, continuous time solv ing, or finite element. Each requires the mathematical model to conform to a certain structure, and some can be combined to create a hybrid MoC. Where sto chastic processes are being modeled or there is uncertainty in system inputs, Monte Carlo simula tions can be performed in order to perform a statistical analysis on output of many simulation runs. There is a trend in simulation environments to separate the execution architecture (that in effect implements the MoC algorithm) and the models of the systems of interest, with the latter being imple mented in a modular form. doing this helps deal with complex models and improves the possibility of reusing models in different simulations. Computer‐ based simulations can be made to cover a broad scope of system attributes and indeed can become quite complex in their own right by including models of many types of systems interacting in many differ ent ways. When the level of complexity becomes such that the expertise necessary to create fit‐for‐ purpose models for different parts of the overall sim ulation is distributed between many subject matter experts, the construction of such simulations becomes in itself an exercise in SE.

• Hardware and/or human‐in‐the‐loop simulations execute in real time and use computer‐based models to close the loop on inputs and outputs with a hardware and or human element of the system. Such simulations have a high level of fidelity but can be costly, especially if physical stimulation is required, for example, motion or visual scene generation.

Within the uS defense community, it is common to refer to simulations as live, virtual, or constructive, where:

• Live simulation refers to live operators operating real systems

• Virtual simulation refers to live operators operating simulated systems

• Constructive simulation refers to simulated opera tors operating with simulated systems

The virtual and constructive simulations may also include actual system hardware and software in the loop as well as stimulus from a real system environment.

9.1.5 developing Models and Simulations

The completed model or simulation can be considered a system or a product in its own right. Therefore, the gen eral steps in the development and application of a model or simulation are closely aligned to the SE processes described within this handbook. Models need to be planned and tracked, just like any other developmental effort.

Executed in parallel and critical to any model and simulation development effort is the verification, valida tion, and accreditation (VV&A) process that certifies that a model or simulation is acceptable for use for a specific purpose. given the consequences of using the knowledge gained from the model or simulation, the user of that knowledge must be confident that the knowledge is of sufficient credibility (i.e., it is “fit for purpose”). This implies that the associated risks of employing the model or simulation in the decision process are mini mized such that it is perceived that the model and simu lation is of more use than not (i.e., the risks of not using the model or simulation are greater than the risks of using the model or simulation). The uS dod Modeling and Simulation Coordination office has committed significant resources to produce comprehensive guidance on VV&A (M&SCo, 2013).

9.1.6 Model and Simulation integration

Many different types of models and simulations may be used as part of a model‐based approach. A key activity is to facilitate the integration of models and simulations across multiple domains and disciplines. As an example, system models can be used to specify the elements of the system. The logical model of the system architecture may be used to identify and partition the elements of the system and define their interconnection or other relation ships among the elements. Quantitative models for performance, physical, and other quality characteristics, such as reliability, may be employed to determine the required values for specific element properties to satisfy the system requirements. An executable system model that represents the interaction of the system elements may be used to validate that the element requirements can satisfy

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

186 CroSS‐CuTTing SySTEMS EnginEEring METhodS

the system behavioral requirements. The aforementioned models each represent different facets of the same system. The different engineering disciplines for electrical, mechanical, and software each create their own models representing different facets of the same system. The dif ferent models must be sufficiently integrated to ensure a cohesive system solution.

To support the integration, the models and simula tions must establish semantic interoperability to ensure that a construct in one model has the same meaning as a corresponding construct in another model. A simple example is the name of a particular element that may appear in a higher‐level system element model, a reliability model, and electrical design model. This modeling information must be exchanged between model ing tools and consistently represented in the different models.

one approach to semantic interoperability is to use model transformations between different models. Transformations are defined which establish correspondence between the concepts in one model and the concepts in another. in addition to establishing correspondence, the tools must have a means to exchange the model data and share the information. There are multiple means for exchanging data between tools, including file exchange, use of APi, and a shared repository.

The use of modeling standards for modeling lan guages, model transformations, and data exchange is an important enabler of integration across modeling domains.

9.1.7 Model Management

Since the system models and simulations are primary artifacts of the SE effort, their management is of particular importance. The management of models and simulations throughout the system life cycle includes configuration management concerns related to version ing and change control. These are complex processes in their own right, particularly when distributed teams may update different aspects of different pieces. Change management techniques such as branch and merge may be employed along with other integration approaches. Another important aspect of model and simulation management is the ongoing validation. As changes are introduced to the models and simulations, the team needs to ensure they remain a sufficient representation of the system for their intended purpose.

9.1.8 Modeling Standards

different types of models are needed to support the analysis, specification, design, and verification of sys tems. Modeling standards play an important role in defining agreed‐upon system modeling concepts that can be represented for a particular domain of interest and enable the integration of different types of models across domains of interest.

Standards for system modeling languages can enable cross‐discipline, cross‐project, and cross‐organization communication. This communication offers the potential to reduce the training requirements for practitioners when transitioning from one project to another and enables the reuse of system artifacts within and across projects and organizations. Standard modeling languages also provide a common foundation for advancing the practice of SE, as do other SE standards.

Modeling standards include standards for modeling languages, data exchange between models, and the trans formation of one model to another to achieve semantic interoperability. A partial list of representative modeling standards can be found under the modeling standards section of SEBoK (2014).

9.1.9 Modeling languages

Modeling languages are generally intended to be both human interpretable and computer interpretable and are specified in terms of both syntax and semantics.

The abstract syntax specifies the model constructs and the rules for constructing the model from its con structs. in the case of a natural language like English, the constructs may include types of words such as verbs, nouns, adjectives, and prepositions, and the rules specify how these words can be used together to form proper sentences. The abstract syntax for a mathematical model may specify constructs to define mathematical functions, variables, and their relationship. The abstract syntax for a logical model may also specify constructs to define logical entities and their relationships such as the inter connection relationship between parts or the precedence relationship between actions. A well‐formed model conforms to its rules, just as a well‐formed sentence must conform to the grammatical rules of the natural language.

The concrete syntax specifies the symbols used to express the model constructs. The natural language, such

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

ModEling And SiMulATion 187

as English or german, can be expressed in text or Morse code. A modeling language may be expressed using graphical symbols and/or text statements. For example, a functional flow model may be expressed using graphical symbols consisting of a combination of graphical nodes and arcs annotated with text, while a simulation mod eling language may be expressed using a text syntax in a programming language such as Fortran or C.

The semantics of a language define the meaning of the constructs. For example, an English word does not have explicit meaning until the word is defined. A sen tence can be grammatically correct, but can still be gib berish if the words are not defined, or be misunderstood if the meaning of the words is ambiguous in the context of their use. The language must give meaning both to the concept of a verb or noun and to the meaning of a specific word that is a verb or noun. Similarly, a modeling con struct that is expressed as a symbol, such as a box or arrow on a flowchart, does not have meaning until it is defined. The box and arrow each represent different con cepts. These concepts must be defined, and the specific boxes and arrows should also be defined. The definitions can be expressed in natural language or other formal isms. For example, the symbols sin(x) and cos(x) repre sent the sine and cosine function, which are defined precisely in mathematics. if the position of a pendulum is defined in terms of sin(θ) and cos(θ), the meaning of the pendulum position is understood in terms of these formalisms.

The SysMlTM from the oMg has emerged as an important modeling language for systems (oMg, 2013b). Summary descriptions of the SysMl diagram types shown in Figure 9.2 are as follows:

• A package diagram (pkg) is used to organize the model into packages that contain other model ele ments. This facilitates model navigation and reuse, as well as access and change control.

• A requirements diagram (req) captures text‐based requirements. having requirements within the model enables fine‐grained traceability from requirement to requirement and between requirements and design, analysis, and verification elements in the model.

• System structure is represented using block diagrams:

– A block definition diagram (bdd) describes the system hierarchy and classifications of system elements.

– An internal block diagram (ibd) depicts the internal structure of a system in terms of how its parts are interconnected using ports and connec tors, describing how the parts within the system are interconnected.

• Behavior is captured in use case, activity, sequence, and state machine diagrams:

– A use case diagram (uc) provides a high‐level description of the system functionality in terms

SysML diagram

Package diagram

Behavior diagram

Requirement diagram

Parametric diagram

Structure diagram

Use case diagram

Activity diagram

Sequence diagram

State machine diagram

Block de�nition diagram

Internal block

diagram

Figure 9.2 SysMl diagram types. From Friedenthal et al. (2012), Figure 3.2. reprinted with permission from Sandy Friedenthal. All other rights reserved.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

188 CroSS‐CuTTing SySTEMS EnginEEring METhodS

of how users and external systems use the system to achieve their goals.

– An activity diagrams (act) represents the trans formation of inputs to outputs through a con trolled sequence of actions.

– A sequence diagram (sd) represents interaction in terms of the time‐ordered exchange of mes sages between collaborating parts of a system.

– A state machine diagram (stm) describes the states of a system or its parts; the transitions between the states; the actions that occur within states or upon transition, entry, or exit; and the events that trigger transitions.

• A parametric diagram (par) represents constraints on system property values as necessary to support detailed engineering analysis. These constraints may include performance, reliability, and mass prop erties, among others. SysMl™ can be integrated with other engineering analysis models and tools to execute the analysis.

SysMl includes an allocation relationship to represent allocation of functions to elements, allocation of logical to physical elements, and other types of allocations. SysMl™ is a general‐purpose modeling language that is intended to support many different model‐based methods, such as structured analysis methods and object‐oriented methods. A particular method may require only a subset of the diagrams. For example, a simplified functional anal ysis method may only require activity diagrams augmented by bdds, ibds, and perhaps requirements diagrams.

For general information on SysMl™, along with links to tool vendors, articles, and books, see the official oMg SysMl™ website at http://www.omgsysml.org.

9.1.10 Modeling and Simulation tools

Models and simulations are created by a modeler using modeling and simulation tools. For physical models (e.g. physical mock‐ups), the modeling tools may include drills, lathes, and hammers. For abstract models, the modeling tools are typically software programs running on a computer. These programs provide the ability to express modeling constructs using a particular modeling language. A word processor can be viewed as a tool used to build text descriptions using natural language. in a similar way, a modeling tool is used to build models

using a modeling language. The tool often provides a tool palette to select symbols and a content area to con struct the model from the graphical symbols or other concrete syntax. A modeling tool typically checks the model to evaluate whether it conforms to the rules of the language and enforces such rules to help the modeler create a well‐formed model. This is similar to the way a word processor checks the text to see that it conforms to the grammar rules for the natural language.

Some modeling and simulation tools are commer cially available products, while others may be created or customized to provide unique modeling solutions. Modeling and simulation tools are often used as part of a broader set of engineering tools, which constitute the system development environment. There is increased emphasis on tool support for standard modeling lan guages that enable models and modeling information to be interchanged among different tools.

9.1.11 indicators of Model Quality

The quality of a model should not be confused with the quality of the design that the model represents. For example, one may have a high‐quality, computer‐aided design model of a chair that accurately represents the design of the chair, yet the design itself may be flawed such that when one sits in the chair, it falls apart. A high‐ quality model should provide a representation sufficient to assist the design team in assessing the quality of the design and uncovering design issues.

Model quality is often assessed in terms of the adher ence of the model to modeling guidelines and the degree to which the model addresses its intended purpose. Typical examples of modeling guidelines include naming conventions, application of appropriate model annota tions, proper use of modeling constructs, and applying model reuse considerations. Specific guidelines are dif ferent for different types of models. For example, the guidelines for developing a geometric model using a computer‐aided design tool may include conventions for defining coordinate systems, dimensioning, and tolerances.

9.1.12 Model and Simulation‐Based Metrics

Models and simulations can provide a wealth of informa tion that can be used for both technical and manage ment metrics to assess the modeling and simulation efforts

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

ModEl‐BASEd SySTEMS EnginEEring 189

and, in many cases, the overall SE effort. different types of models and simulations provide different types of information. in general, models and simulations provide information that enables one to:

• Assess progress

• Estimate effort and cost

• Assess technical quality and risk

• Assess model quality

A model’s progress can be assessed in terms of the com pleteness of the modeling effort relative to the defined scope of the model. Models may also be used to assess progress in terms of the extent to which the requirements have been satisfied by the design or verified through test ing. When augmented with productivity metrics, the model can be used to estimate the cost of performing the required SE effort to deliver the system.

Models and simulations can be used to identify criti cal system parameters and assess technical risks in terms of any uncertainty that lies in those parameters. The models and simulations can also be used to provide addi tional metrics that are associated with its purpose. For example, when the model’s purpose is to support mission and system concept formulation and evaluation, then a key metric may be the number of alternative concepts that are explored over a specified period of time.

9.2 Model‐BaSed SySteMS engineering

This section provides an overview of the model‐based SE (MBSE) methodology including a summary of bene fits of a model‐based approach over a more traditional document‐based approach, the purpose and scope of an MBSE approach, references to a survey of MBSE methods used to perform MBSE, and a brief discussion on model management.

9.2.1 MBSe overview

A number of model and simulation practices have been formalized into SE processes. These processes are the foundation of MBSE. The INCOSE Systems Engineering Vision 2020 (2007) defines MBSE as “the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities

beginning in the conceptual design phase and continuing throughout development and later life cycle phases.”

MBSE enhances the ability to capture, analyze, share, and manage the information associated with the specifi cation of a product, resulting in the following benefits:

• Improved communications among the develop ment stakeholders (e.g., the customer, program management, systems engineers, hardware and software developers, testers, and specialty engi neering disciplines)

• Increased ability to manage system complexity by enabling a system model to be viewed from multiple perspectives and to analyze the impact of changes

• Improved product quality by providing an unam biguous and precise model of the system that can be evaluated for consistency, correctness, and completeness

• Enhanced knowledge capture and reuse of the information by capturing information in more stan dardized ways and leveraging built‐in abstraction mechanisms inherent in model‐driven approaches. This in turn can result in reduced cycle time and lower maintenance costs to modify the design

• Improved ability to teach and learn SE fundamen- tals by providing a clear and unambiguous repre sentation of the concepts

MBSE is often contrasted with a traditional document‐ based approach to SE. in a document‐based SE approach, there is often considerable information generated about the system that is contained in documents and other arti facts such as specifications, interface control documents, system description documents, trade studies, analysis reports, and verification plans, procedures, and reports. The information contained within these documents is often difficult to maintain and synchronize, and difficult to assess in terms of its quality (correctness, complete ness, and consistency).

in an MBSE approach, much of this information is captured in a system model or set of models. The system model is a primary artifact of the SE process. MBSE for malizes the application of SE through the use of models. The degree to which this information is captured in models and maintained throughout the life cycle depends on the scope of the MBSE effort. leveraging an MBSE

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

190 CroSS‐CuTTing SySTEMS EnginEEring METhodS

approach to SE is intended to result in significant improve ments in system requirements, architecture, and design quality; lower the risk and cost of system development by surfacing issues early in the system definition; enhance productivity through reuse of system artifacts; and improve communications among the system development team.

9.2.1.1 Survey of MBSE Methodologies in general, a methodology can be defined as the collection of related processes, methods, and tools used to support a specific discipline (Martin, 1996). That more general notion of methodology can be specialized to MBSE methodology, which we characterize as the collection of related processes, methods, and tools used to support the discipline of SE in a “model‐based” or “model‐driven” context (Estefan, 2008).

in 2008, a survey of candidate MBSE methodologies was published under the auspices of an inCoSE technical publication (Estefan, 2008). Six (6) candidate MBSE methodologies were surveyed: inCoSE object‐ oriented Systems Engineering Method (ooSEM), iBM rational Telelogic harmony‐SE, iBM rational unified Process for Systems Engineering (ruP‐SE), Vitech MBSE Methodology, JPl State Analysis (SA), and dori object‐Process Methodology (oPM). Additional informa tion on these methodologies is available on the inCoSE MBSE initiative Wiki (inCoSE, 2010a).

Two example methods that are included in the SE handbook are the functions‐based SE (FBSE) method in Section 9.3 and ooSEM in Section 9.4. Although the functions‐based method is not referred to as model based, there are other functions‐based methods such as the Vitech MBSE Methodology that are explicitly model based. ooSEM is defined as an end‐to‐end MBSE method, where the artifacts of the method are modeling artifacts that are managed and controlled throughout the SE process.

9.3 FunCtionS‐BaSed SySteMS engineering Method

9.3.1 introduction

FBSE is an approach to SE that focuses on the functional architecture of the system. A function is a characteristic task, action, or activity that must be performed to achieve a desired outcome. A function may be accomplished by one or more system elements comprising equipment (hardware), software, firmware, facilities, personnel, and procedural data.

The objective of FBSE is to create a functional architecture for which system products and processes can be designed and to provide the foundation for defining the system architecture through the allocation of functions and subfunctions to hardware/software, databases, facilities, and operations (e.g., personnel).

FBSE describes what the system will do, not how it will do it. ideally, this process begins only after all of the system requirements have been fully identified. often, this will not be possible, and these tasks will have to be done iteratively, with the functional architecture being further defined as the system requirements evolve.

9.3.1.1 Method Overview The FBSE process is itera tive, even within a single stage in the system life cycle. The functional architecture begins at the top level as a set of functions that are defined in the applicable require ments document or specification, each with functional, performance, and limiting requirements allocated to it (in the extreme, top‐level case, the only function is the system, and all requirements are allocated to it). As shown in Figure 9.3, the next lower level of the functional architecture is developed and evaluated to determine whether further decomposition is required. if it is, then the process is iterated through a series of levels until a functional architecture is complete.

Top-level functions and allocated performance requirements

Repeat for each level

Functional architecture

complete

Evaluate and determine whether

lower level is needed

Develop next level of functional architecture

Figure 9.3 Functional analysis/allocation process. inCoSE SEh v1 Figure 4.3‐1. usage per the inCoSE notices page. All other rights reserved.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

FunCTionS‐BASEd SySTEMS EnginEEring METhod 191

FBSE should be conducted iteratively:

• To define successively lower‐level functions required to satisfy higher‐level functional require ments and to define alternative sets of functional requirements

• With requirements definition, to define mission‐ and environment‐driven performance and to deter mine that higher‐level requirements are satisfied

• To flow down performance requirements and design constraints

• With architecture and design, to refine the defini tion of product and process solutions

At each level of the process, alternative decompositions and allocations may be considered and evaluated for each function and a single version selected. After all of the functions have been identified, then all the internal and external interfaces to the decomposed subfunctions are established. These steps are shown in Figure 9.4.

FBSE examines a defined function to identify all the subfunctions necessary to accomplish that function; all usage modes must be included in the analysis. This activity is conducted to the level of depth needed to support required architecture and design efforts. identified functional requirements are analyzed to deter mine the lower‐level functions required to accomplish the parent requirement. Every function that must be per formed by the system to meet the operational require ments is identified and defined in terms of allocated functional, performance, and other limiting require ments. Each function is then decomposed into subfunc tions, and the requirements allocated to the function are each decomposed with it. This process is iterated until the system has been completely decomposed into basic subfunctions, and each subfunction at the lowest level is

completely, simply, and uniquely defined by its require ments. in the process, the interfaces between each of the functions and subfunctions are fully defined, as are the interfaces to the external world.

identified subfunctions are arranged in a functional architecture to show their relationships and interfaces (internal and external). Functional requirements should be arranged in their logical sequence so that lower‐level functional requirements are recognized as part of higher‐ level requirements. Functions should have their input, output, and functional interface requirements (both internal and external) defined and be traceable from beginning to end conditions. Time critical requirements must also be analyzed.

Performance requirements should be successively established, from the highest to lowest level, for each functional requirement and interface. upper‐level performance requirements are then flowed down and allocated to lower‐level subfunctions. Timing require ments that are prerequisite for a function or set of functions must be determined and allocated. The result ing set of requirements should be defined in measurable terms and in sufficient detail for use as design criteria. Performance requirements should be traceable from the lowest level of the current functional architecture, through the analysis by which they were allocated, to the higher‐level requirement they are intended to support. All of these types of product requirements must also be verified.

note that while performance requirements may be decomposed and allocated at each level of the functional decomposition, it is sometimes necessary to proceed through multiple levels before allocating the performance requirements. Also, sometimes, it is necessary to develop alternative functional architectures and conduct a trade study to determine a preferred one. With each iteration of

Decompose the function into subfunctions

Develop alternative decompositions

Repeat for each function

Decompose requirements

and allocate to subfunctions

Evaluate alternative

decompositions and select one

Identify all internal and

external interfaces

Figure 9.4 Alternative functional decomposition evaluation and definition. inCoSE SEh v1 Figure 4.3‐2. usage per the inCoSE notices page. All other rights reserved.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

192 CroSS‐CuTTing SySTEMS EnginEEring METhodS

FBSE, alternative decompositions are evaluated and all interfaces are defined.

The products of FBSE can take various formats depending on the specific stage of the project and on the specific technique used to develop the functional architecture. The following are some key outputs gener ated from FBSE:

1. Input–process–output (IPO) diagrams—Top‐level diagram of a data flow that is related to a specific level of system decomposition. This diagram por trays all inputs and outputs of a system but shows no decomposition.

2. Behavior diagrams—describe behavior that specifies system‐level stimulus responses using constructs that specify time sequences, concur rencies, conditions, synchronization points, state information, and performance.

3. Control flow diagrams—depict the set of all possible sequences in which operations may be performed by a system or a software program. There are several types of control flow diagrams, including box diagrams, flowcharts, and state transition diagrams.

4. Data flow diagrams (DFDs)—Provide an inter connection of each of the behaviors that the system must perform. All inputs to the behavior desig nator and all outputs that must be generated are identified along with each of the data stores that each must access. Each of the dFds must be checked to verify consistency with the iPo dia gram or higher‐level dFd.

5. Entity relationship (ER) diagrams—depict a set of entities (e.g., functions or architecture elements) and the logical relationships between them.

6. Functional flow block diagrams (FFBDs)—relate the inputs and outputs and provide some insight into flow between the system functions.

7. Integrated definition for functional modeling (IDEF) diagrams—Show the relationship bet ween functions by sequential input and output flows. Process controls enter the top of each repre sented function, and lines entering the bottom show the supporting mechanism needed by the function.

8. Data dictionaries—documentation that provides a standard set of definitions of data flows, data

elements, files, etc. as an aid to communications across the development organizations.

9. Models—Abstractions of relevant characteristics of a system used as a means to understand, com municate, design, and evaluate a system. They are used before the system is built and while it is being verified or in service.

10. Simulation results—output from a simulation of the system that behaves or operates like the Soi when provided a set of controlled inputs.

The objective of the functional decomposition activity is to develop a hierarchy of FFBds that meet all the functional requirements of the system. note, however, that this hierarchy is only a portion of the functional architecture. The architecture is not complete until all of the performance and limiting requirements have been appropriately decomposed and allocated to the elements of the hierarchy, as described earlier.

A description of each function in the hierarchy should be developed to include the following:

1. its place in a network (e.g., FFBd or idEF0/1 diagrams) characterizing its interrelationship with the other functions at its level

2. The set of functional requirements that have been allocated to it and define what it does

3. its inputs and outputs, both internal and external

These various outputs characterize the functional architecture. There is no one preferred output that will support this analysis. in many cases, several of these are necessary to understand the functional architecture and the risks that may be inherent in the system architecture. using more than one of these formats allows for a “check and balance” of the analysis process and will aid in com munication across the system design team.

9.3.2 FBSe tools

Tools that can be used to perform FBSE include:

• Analysis tools

• Modeling and simulation tools

• Prototyping tools

• requirements traceability tools

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

oBJECT‐oriEnTEd SySTEMS EnginEEring METhod 193

9.3.3 FBSe Measures

The following measures can be used to measure the overall process and products of FBSE:

• number of allocation‐related trade studies com pleted as a percent of the number identified

• Percent of analyses completed

• number of functions without a requirements allocation

• number of functions not decomposed

• number of alternative decompositions

• number of internal and external interfaces not com pletely defined

• depth of the functional hierarchy as a percentage versus the target depth

• Percent of performance requirements that have been allocated at the lowest level of the functional hierarchy

9.4 oBjeCt‐oriented SySteMS engineering Method

9.4.1 introduction

ooSEM (Estefan, 2008) integrates object‐oriented con cepts with model‐based and traditional SE methods to help architect flexible and extensible systems that accommodate evolving technologies and changing requirements. ooSEM supports the specification, analysis, design, and verification of systems. ooSEM can also facilitate integration with object‐oriented software development, hardware develop ment, and verification and validation methods.

object‐oriented SE evolved from work in the mid‐1990s at the Software Productivity Consortium in collaboration with lockheed Martin Corporation. The methodology was applied in part to a large, distributed information system development at lockheed Martin that included hardware, software, database, and manual procedure elements. The inCoSE Chesapeake Chapter established the ooSEM Working group in november 2000 to help evolve the meth odology further. ooSEM is described in inCoSE and industry papers (Friedenthal, 1998; lykins et al., 2000) and in A Practical Guide to SysML: The Systems Modeling Language, by Friedenthal et al. (2012).

The ooSEM objectives are as follows:

• Capture information throughout the life cycle sufficient to specify, analyze, design, verify, and val idate systems

• integrate MBSE methods with object‐oriented soft ware, hardware, and other engineering methods

• Support system‐level reuse and design evolution

Figure 9.5 depicts the techniques and concepts that con stitute ooSEM. ooSEM incorporates foundational SE practices, object‐oriented concepts, and other unique techniques to deal with system complexity. Practices recognized as essential to SE are core tenets of ooSEM. These include requirements analysis, trade studies, and integrated Product and Process development (iPPd). See Section 9.7 for more about iPPd, which emphasizes multidisciplinary teamwork in the development process.

object‐oriented concepts that are leveraged in ooSEM include blocks (i.e., classes in uMl) and objects, along with the concepts of encapsulation and inheritance. These concepts are supported directly by SysMl. Techniques that are unique to ooSEM include parametric flow down, system/logical decomposition, requirements vari ation analysis, and several others.

9.4.2 Method overview

The ooSEM supports a development process as illus trated in Figure 9.6.

This development process includes subprocesses to:

• Manage system development—To plan and control the technical effort, including planning, risk management, configuration management, and measurement

• Define system requirements and design, including specifying the system requirements, developing the system architecture, and allocating the system requirements to system elements

• Develop system elements—To design, implement and test the element, which satisfies the allocated requirements

• Integrate and test the system—To integrate the system elements and verify that they satisfy the system requirements, individually and together

This process is consistent with a typical “Vee” process as described in Chapter 3. it can be applied recursively and iteratively at each level of the system hierarchy. For example, if the system hierarchy includes multiple system element levels, the process may be applied at the

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

194 CroSS‐CuTTing SySTEMS EnginEEring METhodS

system level to specify the first level of system element requirements. Then the process can be applied again for each system element at the first level to specify require ments for the system elements at the second level, and so forth.

To be effective, ooSEM development activities must be supported by systems engineers applying fundamental tenets of SE, including the use of multidisciplinary teams

and disciplined management processes such as plann ing, risk management, configuration management, and measure ment. ooSEM development activities and accompanying process flows are more fully described in Object‐Oriented Systems Engineering Method (OOSEM) Tutorial (lMCo, 2008) and in Tutorial Material— Model‐Based Systems Engineering Using the OOSEM (JhuAPl, 2011).

OOSEM unique

Common OOSE

Casual analysis Enterprise model Elaborated model Requirements variation analysis System/logical decomposition Partitioning criteria Node allocation etc.

SE process Requirements Trades etc.

Top down SE approach Recursive SE process Use case/scenario driven (requirement’s — test) Black box/white box OO concepts UML/SysML

SE foundation

Figure 9.5 ooSEM builds on established SE foundations. reprinted with permission from howard lykins. All other rights reserved.

Manage system

development

De�ne system rqmts and

design

OOSEM activities

System element(s)

Test procedures

Procedures Data

Hardware Software

Develop system

element(s)

Integrate and test system

SystemSystem arch and allocated rqmts

PlanStakeholder rqmts

Status and technical data

Figure 9.6 ooSEM activities in context of the system development process. reprinted with permission from howard lykins. All other rights reserved.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

oBJECT‐oriEnTEd SySTEMS EnginEEring METhod 195

The system requirements and design process is decomposed into the following ooSEM high‐level activities, as depicted in Figure 9.7.

9.4.2.1 Analyze Stakeholder Needs This activity supports analysis of both the “as‐is” and the “to‐be” enterprise. in ooSEM, an enterprise aggregates the system with other external systems that work together to accomplish the mission. The “as‐is” systems and enterprise are captured in sufficient detail to understand their limitations and needed improvements. The limita tions of the “as‐is” enterprise, as determined through causal analysis techniques, are the basis for deriving the mission requirements for the “to‐be” enterprise.

ooSEM specifies the mission requirements for the “to‐be” enterprise to reflect customer and other stake holder needs. The mission requirements include defini tion of new and improved capabilities to address the limitations identified in the causal analysis. The capabil ities for the “to‐be” enterprise are represented as use cases with corresponding MoEs. The “to‐be” enterprise sets the context for the system or system(s) to be developed.

The modeling artifacts that support analysis, including use cases, scenario analysis, causal analysis, and context diagrams, can be captured in the customer’s “as‐is” and/ or “to‐be” concept document(s).

9.4.2.2 Analyze System Requirements This activity specifies the system requirements that support the mission requirements. The system is modeled as a black box that interacts with the external systems and users. The use cases and scenarios reflect the operational con cept for how the system is used to support the mission. The scenarios are modeled using activity diagrams with swim lanes that represent the black box system, users, and external systems. The scenarios for each use case are used to derive functional, interface, data, and performance requirements for the black box system. The requirements management database is updated to trace system require ment to use cases and associated mission requirements.

requirements may change as development proceeds. For example, a system’s external interfaces may change, or its performance requirements may increase. require ments variation is evaluated in terms of the probability that a requirement will change and the impact of such change on the mission. These factors are included in the risk assessments and later used to determine how to design the system to accommodate potential require ments changes.

9.4.2.3 Define Logical Architecture This activity includes decomposing and partitioning the system into logical elements, for example, a user interface that will

Analyze stakeholder

needs

Optimize and analyze

alternatives

Manage requirements traceability

Verify and validate system

De�ne logical

architecture

Synthesize candidate physical

architecture

Major SE development

activities

Common subactivities

Analyze system

requirements

Requirements traceability

Test plans

Parametric diagrams Trade studies

Causal analysis Mission use cases/scenarios

System use cases/scenarios Elaborated context Requirements diagram

Logical decomposition

Node diagram HW, SW, data arch System deployment

Logical scenarios Logical subsystems

Enterprise model

Test cases Test procedures

Figure 9.7 ooSEM activities and modeling artifacts. reprinted with permission from howard lykins. All other rights reserved.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

196 CroSS‐CuTTing SySTEMS EnginEEring METhodS

be realized by a web browser or an environmental monitor that will be realized by an infrared sensor. The elements interact to satisfy system requirements and capture system functionality. having a logical architecture/ design mitigates the impact of requirements and tech nology changes on system design.

ooSEM provides guidelines for decomposing the system into its logical elements. Functions for logical elements are derived from logical scenarios to support black box system functions. logical element function ality and data may be repartitioned based on other cri teria, such as cohesion, coupling, design for change, reliability, and performance.

9.4.2.4 Synthesize Candidate Physical Architectures The physical architecture describes relationships among physical system elements, including hardware, soft ware, data, people, and procedures. logical elements are allocated to physical elements. For distributed systems, ooSEM includes guidance for distributing the physical elements across the system nodes to address concerns, such as performance, reliability, and security. The system architecture continues to be refined to address concerns associated with the software, hardware, and data architectures. requirements for each physical element are traced to the system require ments and maintained in the requirements management database.

9.4.2.5 Optimize and Evaluate Alternatives This activity is invoked throughout all other ooSEM activ ities to optimize the candidate architectures and conduct trade studies to select an architecture. Parametric models for modeling performance, reliability, availability, life cycle cost, human, and other specialty engineering con cerns are used to analyze and optimize the candidate architectures to the level needed to compare the alterna tives. Criteria and weighting factors used to perform the trade studies are traced to the system requirements and MoEs. TPMs are monitored, and potential risks are identified.

9.4.2.6 Manage Requirements Traceability This activity is performed throughout the other ooSEM activities to ensure traceability between requirements, architecture, design, analysis, and verification elements. requirements relationships are established and main tained. requirements in the system model are synchronized

with the requirements management database. Traceability is continuously analyzed to assess and fill gaps or defi ciencies. As requirements change, traceability is used to assess the impact of requirements changes on the system design, analysis, and verification elements.

9.4.2.7 Validate and Verify System This activity verifies that the system design satisfies its requirements and validates that those requirements meet the stake holder needs. Verification plans, procedures, and methods (e.g., inspection, demonstration, analysis, and test) are developed. The primary inputs to the development of the test cases and associated verification procedures are system‐level use cases, scenarios, and associated require ments. The verification system can be modeled using the same activities and artifacts described earlier for modeling the operational system. The requirements management database is updated during this activity to trace the system requirements and design information to the system verification methods, test cases, and results.

9.4.3 applying ooSeM

ooSEM is an MBSE method used to specify and design systems. These include not only the operational system such as an aircraft or an automobile but also systems that enable the operational system throughout its life cycle, such as manufacturing, support, and verification sys tems. The method may also be applied to architect a system of systems or an enterprise, as well as to architect individual systems, or even system elements.

ooSEM should be tailored to support specific applications, project needs, and constraints. Tailoring may include varying the degree of emphasis on a particular activity and associated modeling artifacts and/or sequencing activities to suit a particular life cycle model.

The modeling artifacts can also be refined and reused in other applications to support product line and evolu tionary development approaches. Product line modeling concerns the modeling of variability. Three refinements are to be considered in order to ensure what could be called as a “model‐based product line SE”:

• The modeling of the variability and the constraints between these variabilities for each type of arti facts: needs, requirements, architecture, tests, and others.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

inTErFACE MAnAgEMEnT 197

• The modeling of the variability for each type of SysMl diagrams: Activity diagrams, use cases, and others.

• The modeling of the dependency links between these artifacts and the constraints between these variabilities to explain the relationship between them: As an example for a product line of water heaters, the variability of the electrical resistance component power depends, or not, on the vari ability of the water heater capacity.

ooSEM can be used in conjunction with principles and practices from various schools of thought, such as agile software development. Again, this requires adapting and tailoring how ooSEM is applied to integrate with the other approaches.

9.5 PrototyPing

Prototyping is a technique that can significantly enhance the likelihood of providing a system that will meet the user’s need. in addition, a prototype can facilitate both the awareness and understanding of user needs and stakeholder requirements. Two types of prototyping are commonly used: rapid and traditional.

rapid prototyping is probably the easiest and one of the fastest ways to get user performance data and eval uate alternate concepts. A rapid prototype is a particular type of simulation quickly assembled from a menu of existing physical, graphical, or mathematical elements. Examples include tools such as laser lithography or com puter simulation shells. They are frequently used to investigate form and fit, human–system interface, opera tions, or producibility considerations. rapid prototypes are widely used and are very useful; but except in rare cases, they are not truly “prototypes.”

Traditional prototyping is a tool that can reduce risk or uncertainty. A partial prototype is used to verify critical elements of the Soi. A full prototype is a complete repre sentation of the system. it must be complete and accurate in the aspects of concern. objective and quantitative data on performance times and error rates can be obtained from these higher‐fidelity interactive prototypes.

The original use of a prototype was as the first‐of‐a‐ kind product from which all others were replicated. however, prototypes are not “the first draft” of production entities. Prototypes are intended to enhance learning and

should be set aside when this purpose is achieved. once the prototype is functioning, changes will often be made to improve performance or reduce production costs. Thus, the production entity may require different behavior. The maglev train system (see Section 3.6.3) may be consid ered a prototype (in this case, proof of concept) for longer distance systems that will exhibit some but not all of the characteristics of the short line. Scientists and engineers are in a much better position to evaluate modifications that will be needed to create the next system because of the existence of a traditional prototype.

9.6 interFaCe ManageMent

interface management is a proven set of activities that cut across the SE processes. Although some organizations treat interface management as a separate process, these are crosscutting activities of the technical and technical management processes that the project team should apply and track as a specific view of the system. When interface management is applied as a specific objective and focus of the technical processes, it will often help highlight underlying critical issues much earlier in the project than would otherwise be revealed. This would then impact upon project cost, schedule, and technical performance.

interfaces are identified within the architecture defini tion process (Section 4.4), as the architecture models are developed. The interface requirements are defined through the system requirements definition process (Section 4.3). As the requirements are defined, the inter face descriptions and definitions are defined to the extent needed for the architecture description within the architecture definition process (Section 4.4). Any further refinement and detail of the interface definition is provided by the design definition process (Section 4.5) as the details of the specific system implementation details are defined. The evolution of the system defini tion involves iteration between these processes, and the interface definition is an essential part of it. As the inter face identification and definition evolve in the architecture definition process, there is an objective of keeping the interfaces as simple as possible (Fig. 4.8).

As part of the interface definition, many projects find the need or benefit to apply interface standards. in some cases, such as for plug‐and‐play elements or interfaces across open systems, it is necessary to strictly apply

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

198 CroSS‐CuTTing SySTEMS EnginEEring METhodS

interface standards to ensure the necessary interopera tion with systems for which the project team does not control. Examples of these standards include internet Protocol standards and Modular open Systems Architecture standards. interface standards can also be beneficial for systems that are likely to have emergent requirements by enabling the evolution of capabilities through the use standard interface definitions that allow new system elements to be added.

good communication is a vital part of ensuring the inter face management of a system. Many projects incorporate the use of an interface Control Working group (iCWg), which include members responsible for each of the inter facing elements. The iCWg can be focused on internal interfaces within a single system or the external interfaces between interoperating or enabling systems. The use of iCWgs formalizes and enhances collaboration within project teams or between project teams/organizations. The use of iCWgs is an effective approach that helps to ensure adequate consideration of all aspects of the interfaces.

one of the objectives of the interface management activities is to facilitate agreements with other stake holders. This includes roles and responsibilities, the timing for providing interface information, and the identification of critical interfaces early in the project through a struc tured process. This is done through the project planning process (Section 5.1). Through specific interface focus as a part of the risk management process (Section 5.4), early identification of issues, risks, and opportunities can be

managed, avoiding potential impacts, especially during integration. interface management also enhances relation ships between the different organizations, giving an open communication system of issues and cooperation, where problems can be resolved more effectively.

Finally, after establishing baselines for requirements, architecture, and design artifacts, the configuration mana ge ment process (Section 5.5) provides the ongoing management and control of the interface requirements and definitions, as well as any associated artifacts (such as interface control documents, interface requirement speci fications, and interface description/definition documents).

interface management is intended to provide a simple but effective method to formally document and track the exchange of information as the life cycle processes are performed.

9.6.1 interface analysis Methods

There are several analysis methods and tools that aid the interface definition. These methods help to identify and understand the interfaces in the context of the system, the system elements, and/or the interfacing systems. generally, the system analysis process (Section 4.6) is invoked by the system requirements definition, architecture definition, or design definition processes to perform the interface analysis.

N2 diagrams (see Fig. 9.8) are a systematic approach to analyze interfaces. These apply to system interfaces,

External input

B to

A to

Interfaces �ow clockwise (outputs horizontal, inputs vertical)

to D

C D

A C

FFBD N2 diagram

C to

D to

External output External

output

Figure 9.8 Sample FFBd and N2 diagram. inCoSE SEh original figure created by Krueger and Forsberg. usage per the inCoSE notices page. All other rights reserved.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

inTEgrATEd ProduCT And ProCESS dEVEloPMEnT 199

equipment (e.g., hardware) interfaces, or software inter faces. N2 diagrams can also be used at later stages of the development process to analyze and document physical interfaces between system elements. For effective appli cation, an N2 diagram, which is a visual matrix, requires the systems engineer to generate complete definitions of all the system interfaces in a rigid bidirectional, fixed framework.

The system functions or physical elements are placed on the chart diagonal. The rest of the squares in the N × N matrix represent the interface inputs and outputs. interfaces between functions flow in a clockwise direction. The entity being passed from function A to function B, for example, can be defined in the appro priate square. When a blank appears, there is no interface between the respective functions. When all functions have been compared to all other functions, then the chart is complete. if lower‐level functions are identified in the process with corresponding lower‐level interfaces, then they can be successively described in expanded or lower‐ level diagrams. Sometimes, characteristics of the entity passing between functions may be included in the box where the entity is identified. one of the main functions of the chart, besides interface identification, is to pin point areas where conflicts may arise between functions so that systems integration later in the development cycle can proceed efficiently (Becker et al., 2000; dSMC, 1983; lano, 1977).

Alternatively, or in addition, FFBds and dFds can be used to characterize the flow of information among functions and between functions and the outside world. As the system architecture is decomposed to lower and lower levels, it is important to make sure that the inter face definitions keep pace and that interfaces are not defined that ignore lower‐level decompositions.

other analysis methods that may be useful for inter face definition include design Structure Matrix (dSM) and the ibd (SysMl).

• “design Structure Matrix (dSM) is a straightforward and flexible modeling technique that can be used for designing, developing, and managing complex sys tems. dSM offers network modeling tools that repre sent the elements of a system and their interactions, thereby highlighting the system’s architecture (or designed structure).” The dSM is very similar in appearance and usage to the N2 diagram, but a differ ent input and output convention is typically used

(inputs on the horizontal rows and outputs on the vertical columns) (Eppinger and Browning, 2012).

• The ibd specifies the interconnection of parts of the system in SysMl (see Section 9.1.9). They are used to describe the internal structure of a system in terms of its parts, ports, and connectors. The ibd provides the white box, or internal view, of a system block to represent the final assembly of all blocks within the main system block (Friedenthal et al., 2012).

9.7 integrated ProduCt and ProCeSS develoPMent

Integrated Product Development (iPd) recognizes the need to consider all elements of the product life cycle, from conception through disposal, starting at the beginning of the life cycle. important items to consider include quality, cost, schedule, user requirements, manufacturing, and support. iPd also implies the continuous integration of the entire product team, including engineering, manu facturing, verification, and support, throughout the prod uct life cycle (dod, 1998).

risks inherent in concurrent product development are reduced by moving away from traditional hierarchical management structure and organized into integrated Product Teams (iPTs). Productivity gains come through decentralization of processes, avoidance of previous problems, and better integration between engineering and manufacturing. Traditional development with serial activities may be so lengthy such that the product becomes obsolete before it is completed. With good interface definition and control, iPd, involving the entire team, can speed up the development process.

iPPd further recognizes the importance of process. The following definitions apply to iPPd:

• Integrated Product Development Team (IPDT)—A multidisciplinary group of people who are collec tively responsible for delivering a defined product or process.

• IPPD—The process of using iPdTs to simultaneously develop the design for a product or system and the methods for manufacturing the product or system. The process verification may consist of review of a process description by an iPdT. it may also include a demonstration to an iPdT of a process.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

200 CroSS‐CuTTing SySTEMS EnginEEring METhodS

• Concurrent engineering—is a management/ operational approach that aims to improve product design, production, operation, and maintenance by developing environments in which personnel from all disciplines (e.g., design, marketing, production engineering, process planning, and support) work together and share data throughout all stages of the product life cycle.

integrated development has the potential to introduce more risk into a development program because down stream activities are initiated on the assumption that upstream activities will meet their design and interface requirements. however, the introduction of a hierarchy of cross‐functional iPdTs, each developing and deliv ering a product, can reduce risks and provide better prod ucts faster.

iPPd also improves team communications through iPdTs, implements a proactive risk process, makes decisions based on timely input from the iPdT, and improves customer involvement.

9.7.1 iPdt overview

An iPdT is a process‐oriented, integrated set of cross‐ functional teams (i.e., an overall team comprising many smaller teams) given the appropriate resources and charged with the responsibility and authority to define, develop, produce, and support a product or process (and/ or service). Each team is staffed with the skills necessary

to complete their assigned processes, which may include all or some of the development and production steps.

The general approach is to form cross‐functional iPdTs for all products and services. The typical types of iPdTs are a Systems Engineering and integration Team (SEiT), a Product integration Team (PiT), and a Product development Team (PdT). These teams each mimic a small, independent project focusing on individual ele ments and/or their integration into more complex system elements. The SEiT balances requirements between product teams, helps integrate the other iPdTs, focuses on the integrated system and system processes, and addresses systems issues, which, by their nature, the other iPdTs would most likely relegate to a lower pri ority. Although the teams are organized on a process basis, the organizational structure of the team of teams may approach a hierarchical structure for the product, depending upon the way the product is assembled and integrated.

The focus areas for these iPdT team types and their general responsibilities are summarized in Table 9.1. This arrangement often applies to large, multielement, multiple subsystem programs but must be adapted to the specific project. For example, on smaller programs, the number of PiT teams can be reduced or eliminated. in service‐oriented projects, the system hierarchy, focus, and responsibilities of the teams must be adapted to the appropriate services.

Team members’ participation will vary throughout the product cycle, and different members may have

taBle 9.1 types of iPdts and their focus and responsibilities

System hierarchy Team type + focus responsibilities

External interface and system Systems engineering and integration team (SEiT) • Integrated system and processes • External and program issues • System issues and integrity • Integration and audits of teams

upper‐level elements Product integration Teams (PiTs) • Integrated H/W and S/W • Deliverable item issues and integrity • Support to other teams (SEIT and PDTs)

lower‐level elements Product development Teams (PdTs) • Hardware and software • Product issues and integrity • Primary participants (design and Mfg.) • Support to other teams (SEIT and PITs)

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

inTEgrATEd ProduCT And ProCESS dEVEloPMEnT 201

primary, secondary, or minor support roles as the effort transitions from requirements development through the different stages of the life cycle. For example, the manu facturing and verification representatives may have minor, part‐time advisory roles during the early product definition stage but will assume primary roles later, dur ing manufacture and verification. Team members partic ipate to the degree necessary from the outset to ensure their needs and requirements are reflected in overall project requirements and planning to avoid costly changes later. it is also good for some of the team to remain throughout the product cycle to retain the team’s “project memory.”

iPdTs must be empowered with full life cycle respon sibility for their products and systems and with the authority to get the job done. They should not be looking to higher management for key decisions. They should, however, be required to justify their actions and decisions to others, including interfacing teams, the systems integration team, and project management.

9.7.2 iPdt Process

The basic principle of iPdT is to get all disciplines involved at the beginning of product development to ensure that needs and requirements are completely under stood for the full life cycle of the product. requirements are developed initially at the system level, then succes sively at lower levels as the requirements are flowed down. Teams, led by systems engineers, perform the up‐front SE activities at each level.

iPdTs do their own internal integration in an iPPd environment. A SEiT representative belongs to each product team (or several) with internal and external team responsibilities. There is extensive iteration between the product teams and the SEiT to converge on requirements and design concepts, although this effort should slow down appreciably after the preliminary design review and as the design firms up.

Systems engineers participate heavily in the SEiT and PiT and to a much lesser extent in the PdT. regardless, the iterative SE processes described in this handbook are just as applicable to all teams in the iPPd environment. it is even easier to apply the processes throughout the program because of the day‐to‐day presence of systems engineers on all teams.

iPdTs have many roles, and their integration roles overlap based on the type of team and the integration

level. Figure 9.9 gives examples of program processes and system activities.

The three bars on the left show the roles of the types of product teams at different levels of the system. For example, the SEiT leads and audits in external integration and in systems integration activities, as indi cated by the shaded bar. For program processes involving lower‐level elements (e.g., parts, components, or subassemblies), the appropriate PdTs are the active lead and audit participants, supported by the SEiT and the PiT.

Basic system activities include system requirements derivation, system functional analysis, requirements allocation and flowdown, system trade‐off analysis, system synthesis, systems integration, TPM definition, and system verification. The bars for system functions 1, 2, and 3 in the chart show that the SEiT leads and audits activities on different system activities while the element teams participate. The lower‐level system element teams provide additional support, if requested.

The column at the right side of Figure 9.9 shows other integration areas where all teams have some involve ment. The roles of the various teams must also be coor dinated for these activities but should be similar to the example.

9.7.2.1 Organizing and Running a High‐Performance IPDT The basic steps and key activities to organize and run an iPdT are as follows:

1. Define the IPDT teams for the project—develop iPdT teams that cover all project areas.

2. Delegate responsibility and authority to IPDT leaders—Select experienced team leaders early in the development process and avoid frequent budget changes throughout the life cycle.

3. Staff the IPDT—Candidates must work well in a team environment, communicate well, and meet their commitments:

• Balance the competency, availability, and full‐ time commitment of the core team.

• Plan when competencies are needed and not needed.

• identify issues where specialists are needed.

4. Understand the team’s operating environment— recognize how the team directly or indirectly influences other teams and the project as a whole.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

202 CroSS‐CuTTing SySTEMS EnginEEring METhodS

5. Plan and conduct the “kick‐off meeting”— recommend two kick‐off meetings, one for the project as a whole and one for the individual iPdTs. Well‐planned kick‐off meetings will set the project off on the right foot.

6. Train the team—Training for the project is a criti cal element. The following recommended topics should be covered:

• Tailored SE process for the project

• Project description, stakeholders, purpose, mission, organization, schedule, and budget

• Terminology and nomenclature

• Access to project products

• Communications skills

• Project iPdT procedures, measures, and reporting

Additional training sessions should be held and self‐learning guides should be developed to help new team members come up to speed on the project when staff turnover occurs.

7. Define the team vision and objectives—use col laborative brainstorming in the initial iPdT meet ings to develop the team’s vision and objectives such that each member has an ownership. it most likely will be necessary to bring in other iPdT members, management, and customers to flesh out the vision and objectives of the team.

8. Have each team expand the definition of its job— once the higher‐level project plan has been reviewed, each team must identify the tasks, roles, responsibil ities, and milestones of the team and each of the mem bers. Members need to understand how their individual tasks fit into the higher‐level project–program tasks.

9. Establish an expectation of routine process assessment and continuous improvement—Each team must document the process they are using and the key measures to be monitored. The teams must have the mindset of continuous improve ment, monitor their own activities, and continually make course corrections along the way.

External

Program processes

SEIT

PIT

PDT

System functions

Other integration areas

System

Element

SubsystemU pp

er le

ve l

sy st

em e

le m

en ts

Level

L ow

er le

ve l

sy st

em e

le m

en ts Assembly

S S

f1 f2 f3

L & A

P & S

L & A

P P

End-to-end issues Operations Deployment Mission algorithms Real-time simulation Demostration

Top-to-bottom issues Data system Cost engineering Speciality engineering Trade studies

Interfaces External Internal elements

Cost and schedule control Current and follow-on systems

SComponent

Part

Team responsibilies: L, lead; S, support; P, participate; A, audit.

Figure 9.9 Examples of complementary integration activities of iPdTs. Adapted from Bob lewis as inCoSE SEh v1 Figure 6.3. usage per the inCoSE notices page. All other rights reserved.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

lEAn SySTEMS EnginEEring 203

10. Monitor team progress via measures and reports— Each team will have a set of measures and reports to monitor its own progress. These reports and measures must be reviewed by the SEiT that coor dinates among the other iPdTs. These measures may include an earned value report and technical measures, such as a defect rate report. The selected measures are dependent on the team’s role on the project.

11. Sustain and evolve the team throughout the project—Personnel assignments to a team will vary as each team grows, shrinks, and changes skill mix over the project life cycle. As issues arise, technical specialists may need to join the team to help address these specific issues. Services such as marketing, program controls, procure ment, finance, legal, and human resources gener ally support the team at a steady, low level of effort, or as required.

12. Document team products—The team’s products should be well defined. Because of the iPdT structure, the overhead of cross‐organizational communication varies and should be reduced. When multiple docu ments are required, different team members with identified backups should be assigned as the respon sible author with contributions from others. The iPdT should maintain a log of activities in addition to the mission, vision, objectives, deliverables, meeting minutes, decisions, tailored processes, agreements, team project information, and contact information.

13. Close the project and conduct follow‐up activ- ities—in conjunction with step 12, the iPdT should maintain records as though the project may be reengineered at some future time and all closeout products must be accessible. All iPdT logs should be organized the same way, when pos sible, such that they can be easily integrated into an overall project report. The closeout should include lessons learned, recommended changes, and a summary of measures for the team.

Project managers should review team staffing plans to ensure proper composition and strive for continuity of assignments. The advantages of a full‐time contributor outweigh the work of many part‐time team members. Similarly, the loss of a knowledgeable key team member can leave the team floundering. it is important to have

people who can work well together and communicate, but team results may suffer without outstanding technical specialists and professionals who can make a difference. recommended techniques for achieving high performance in an iPdT are as follows:

• Carefully select the staff—Excellent people do excellent work.

• Establish and maintain positive team interaction dynamics—All should know what is expected of the team and each individual and strive to meet commitments. Anticipate and surface potential problems quickly (internally and externally). interactions should be informal but efficient and a “no blame” environment where problems are fixed and the team moves on. Acknowledge and reward good work.

• Generate team commitment and buy‐in—Team alignment to the vision, objectives, tasks, and schedules. Maintain a team leader’s notebook.

• Breakdown the job into manageable activities— Those that can be accurately scheduled, assigned, and followed up on weekly.

• Delegate and spread out routine administrative tasks among the team—Free up the leader to partic ipate in technical activities. give every team member some administrative/managerial experience.

• Schedule frequent team meetings with mandatory attendance for quick information exchanges— Ensure everyone is current. Assign action items with assignee and due date.

9.7.3 Potential iPdt Pitfalls

There are ample opportunities to go astray before team members and leaders go through several project cycles in the iPdT framework and gain the experience of working together. Table 9.2 describes some pitfalls common to the iPdT environment that teams should watch out for.

9.8 lean SySteMS engineering

SE is regarded as an established, sound practice, but not always delivered effectively. recent uS government Accountability office (gAo, 2008) and nASA (2007a) studies of space systems document major budget and

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

204 CroSS‐CuTTing SySTEMS EnginEEring METhodS

schedule overruns. Similarly, recent studies by the MiT‐ based lean Advancement initiative (lAi) have identi fied a significant amount of waste in government programs, averaging 88% of charged time (lAi MiT, 2013; McManus, 2005; oppenheim, 2004; Slack, 1998). Most programs are burdened with some form of waste: poor coordination, unstable requirements, quality prob lems, and management frustration. This waste represents a vast productivity reserve in programs and major oppor tunities to improve program efficiency.

lean development and the broader methodology of lean thinking have their roots in the Toyota “just‐in‐time” philosophy, which aims at “producing quality products efficiently through the complete elimination of waste, inconsistencies, and unreasonable requirements on the production line” (Toyota, 2009). lean SE is the applica tion of lean thinking to SE and related aspects of organi zation and project management. SE is focused on the discipline that enables flawless development of complex technical systems. lean thinking is a holistic paradigm that focuses on delivering maximum value to the cus tomer and minimizing wasteful practices. A popular description of lean is “doing the right job right the first time” and “working smarter, not harder.” lean thinking has been successfully applied in manufacturing, aircraft depots, administration, supply chain management, health care, and product development, including engineering.

lean SE is the area of synergy between lean thinking and SE, with the goal to deliver the best life cycle value for technically complex systems with minimal waste. The early use of the term lean SE is sometimes met with

concern that this might be a “repackaged faster, better, cheaper” initiative, leading to cuts in SE at a time when the profession is struggling to increase the level and quality of SE effort in programs. lean SE does not take away anything from SE and it does not mean less SE. it means more and better SE with higher responsibility, authority, and accountability, leading to better, waste‐ free workflow with increased mission assurance. under the lean SE philosophy, mission assurance is nonnego tiable, and any task that is legitimately required for suc cess must be included, but it should be well planned and executed with minimal waste.

lean thinking: “lean thinking is the dynamic, knowledge‐driven, and customer‐focused process through which all people in a defined enterprise con tinuously eliminate waste with the goal of creating value” (Murman, 2002).

Lean SE: The application of lean principles, practices, and tools to SE to enhance the delivery of value to the system’s stakeholders.

Three concepts are fundamental to the understanding of lean thinking: value, waste, and the process of creating value without waste (also known as lean principles).

9.8.1 value

The value proposition in engineering programs is often a multiyear, complex, and expensive acquisition pro cess involving numerous stakeholders and resulting in

taBle 9.2 Pitfalls of using iPdt

iPdT pitfalls What to do

Spending too much time defining the vision and objectives Converge and move on insufficient authority—iPdT members must frequently check

with management for approval give team leader adequate responsibility, or put the manager

on the team iPdT members are insensitive to management issues and

overcommit or overspend Team leader must remain aware of overall project objectives

and communicate to team members Teams are functionally oriented rather than cross‐functionally

process oriented review the steps in organizing and running an iPdT (see

preceding text) insufficient continuity of team members throughout the project Management should review staffing requirements Transition to the next stage team specialists occurs too early or

too late in the schedule review staffing requirements

overlapping assignments for support personnel compromises their effectiveness

reduce the number of teams

inadequate project infrastructure Management involvement to resolve

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

lEAn SySTEMS EnginEEring 205

hundreds or even thousands of requirements, which, notoriously, are rarely stable. in lean SE, “value” is defined simply as mission assurance (i.e., the delivery of a flawless complex system, with flawless technical performance, during the product or mission development life cycle) and satisfying the customer and all other stakeholders, which implies completion with minimal waste, minimal cost, and the shortest possible schedule.

“Value is a measure of worth (e.g., benefit divided by cost) of a specific product or service by a customer, and potentially other stakeholders and is a function of (1) the product’s usefulness in satisfying a customer need, (2) the relative importance of the need being satisfied, (3) the availability of the product relative to when it is needed, and (4) the cost of ownership to the customer” (McManus, 2004).

9.8.2 Waste in Product development

The lAi classifies waste into seven categories: overpro cessing, waiting, unnecessary movement, overproduc tion, transportation, inventory, and defects (McManus, 2005). lately, the eighth category is increasingly added: the waste of human potential.

Waste: “The work element that adds no value to the product or service in the eyes of the customer. Waste only adds cost and time” (Womack and Jones, 1996).

When applying lean thinking to SE and project planning, consider each waste category and identify areas of waste ful practice. The following illustrates some waste con siderations for SE practice in each of the lAi waste classifications:

• Overprocessing—Processing more than necessary to produce the desired output. Consider how pro jects “overdo it” and expend more time and energy than needed:

– Too many hands on the “stuff” (material or information)

– unnecessary serial production

– Excessive/custom formatting or reformatting

– Excessive refinement, beyond what is needed for value

• Waiting—Waiting for material or information, or information or material waiting to be processed. Consider “things” that projects might be waiting for to complete a task:

– late delivery of material or information

– delivery too early—leading to eventual rework

• Unnecessary movement—Moving people (or peo ple moving) to access or process material or information. Consider any unnecessary motion in the conduct of the task:

– lack of direct access—time spent finding what you need

– Manual intervention

• Overproduction—Creating too much material or information. Consider how more “stuff” (e.g., material or information) is created than needed:

– Performing a task that nobody needs or using a useless metric

– Creating unnecessary data and information

– information overdissemination and pushing data

• Transportation—Moving material or information. Consider how projects move “stuff” from place to place:

– unnecessary hand‐offs between people

– Shipping “stuff” (pushing) when not needed

– incompatible communication—lost transportation through communication failures

• Inventory—Maintaining more material or information than is needed. Consider how projects stockpile information or materials:

– Too much “stuff” buildup

– Complicated retrieval of needed “stuff”

– outdated, obsolete information

• Defects—Errors or mistakes causing the effort to be redone to correct the problem. Consider how projects go back and do it again:

– lack of adequate review, verification, or validation

– Wrong or poor information

• Waste of human potential—not utilizing or even suppressing human enthusiasm, energy, creativity, and ability to solve problems and general willing ness to perform excellent work.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

206 CroSS‐CuTTing SySTEMS EnginEEring METhodS

9.8.3 lean Principles

Womack and Jones (1996) captured the process of cre ating value without waste into six lean principles. The principles (see Fig. 9.10) are abbreviated as value, value stream, flow, pull, perfection, and respect for people and are defined in detail in the following.

When applying lean thinking to SE, evaluate project plans, preparations of people, processes and tools, and organization behaviors using the lean principles. Consider how the customer defines value in the products and processes, then describe the value stream for cre ating products and processes, optimize flow through that value stream and eliminate waste, encourage pull from each node in that value stream, and strive to perfect the value stream to maximize value to the customer. These activities should all be conducted within a foundation of respect for customers, stakeholders, and project team members.

in 2009, the inCoSE lean SE Working group released a new online product entitled Lean Enablers for Systems Engineering (lEfSE), Version 1.0. it is a

collection of practices and recommendations formulated as “do’s” and “don’ts” of SE based on lean thinking. The practices cover a large spectrum of SE and other relevant enterprise management practices, with a gen eral focus on improving program value and stakeholder satisfaction and reducing waste, delays, cost overruns, and frustrations. lEfSE are currently listed as 147 prac tices (referred to as subenablers) organized under 47 nonactionable topical headings called enablers and grouped into the six lean principles described below (oppenheim, 2011):

1. under the value principle, subenablers promote a robust process of establishing the value of the end product or system to the customer with crystal clarity early in the program. The process should be customer focused, involving the customer fre quently and aligning employees accordingly.

2. The subenablers under the value stream principle emphasize detailed program planning and waste‐ preventing measures, solid preparation of the

Specify value from the

perspective of the customer

Always compete against

perfection, not just your current competition

Deliver only what is

wanted when it is needed

Provide an environment of mutual respect,

trust, and cooperation

Characterize the value stream

for each product/ process and identify

waste

Make work elements ow continuously

with minimal queues, no

rework, no stoppages or

backows

Value

Perfection

Pull Flow

Respect

Value stream

Figure 9.10 lean development principles. reprinted with permission from Bohdan oppenheim. All other rights reserved.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

AgilE SySTEMS EnginEEring 207

personnel and processes for subsequent efficient workflow, and healthy relationships between stakeholders (e.g., customer, contractor, suppliers, and employees); program frontloading; and use of leading indicators and quality measures. Systems engineers should prepare for and plan all end‐to‐ end linked actions and processes necessary to realize streamlined value, after eliminating waste.

3. The flow principle lists subenablers that promote the uninterrupted flow of robust quality work and first‐time right products and processes, steady competence instead of hero behavior in crises, excellent communication and coordination, con currency, frequent clarification of the require ments, and making program progress visible to all.

4. The subenablers listed under the pull principle are a powerful guard against the waste of rework and overproduction. They promote pulling tasks and outputs based on internal and external customer needs (including rejecting others as waste) and better coordination between the pairs of employees handling any transaction before their work begins so that the result can be first‐time right.

5. The perfection principle promotes excellence in the SE and organization processes, the use of the wealth of lessons learned from previous programs in the current program, the development of perfect collab oration policy across people and processes, and driving out waste through standardization and con tinuous improvement. imperfections should be made visible in real time, and continuous improve ment tools (root cause analysis and permanent fix) should be applied. A category of these subenablers calls for a more important role of systems engineers, with responsibility, accountability, and authority for the overall technical success of the program.

6. Finally, the respect‐for‐people principle contains subenablers that promote the enterprise culture of trust, openness, honesty, respect, empowerment, cooperation, teamwork, synergy, and good com munication and coordination and enable people for excellence.

in 2011, a follow‐on major project undertaken jointly by the Project Management institute (PMi), inCoSE, and the lAi at Massachusetts institute of Technology in the leading role developed Lean Enablers for Managing

Engineering Programs (LEfMEP) (oehmen, 2012), incorporating all lEfSE, adding lean enablers for project and program management, and holistically integrating lean program management with lean SE. A major section of the book is devoted to a rigorous analysis of chal lenges in managing engineering programs. They are pre sented under the following 10 top challenge themes:

1. Firefighting—reactive program execution

2. unstable, unclear, and incomplete requirements

3. insufficient alignment and coordination of the extended enterprise

4. Processes that are locally optimized and not integrated for the entire enterprise

5. unclear roles, responsibilities, and accountability

6. Mismanagement of program culture, team com petency, and knowledge

7. insufficient program planning

8. improper metrics, metric systems, and key performance indicators

9. lack of proactive program risk management

10. Poor program acquisition and contracting practices

The 326 lean enablers in oehmen (2012) are listed in several convenient ways: under the six lean principles, under the 10 major challenge themes, under the SE processes used in this volume, and under the management performance domains defined in (PMi, 2013).

The lEfSE and lEfMEP are not intended to become mandatory practices. instead, they should be used as a checklist of excellent holistic practices validated by the community of practice. Awareness of the enablers should improve the thinking at work and significantly improve program quality. Early feedback from the organizations practicing lean enablers indicates significant benefits (oppenheim, 2011).

The INCOSE Lean SE Working Group public website (2011) contains a rich menu of publications and case studies related to both lEfSE and lEfMEP.

9.9 agile SySteMS engineering

historically, agile software engineering processes came into awareness in 2001 with the declaration of the Agile Manifesto (Beck et al., 2001), which spawned interest in

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

208 CroSS‐CuTTing SySTEMS EnginEEring METhodS

a number of methodologies, with names such as Scrum and Extreme Programming. But adoption of those meth odologies and consideration of how they might inform nonsoftware engineering (Carson, 2013) has tended to focus on software‐related specific practices rather than fundamental frameworks. in contrast, a cross‐industry study in 1991 (nagel, 1992) observed that technology and the environment in which it is deployed were coevolving at an increasing rate, outpacing the adaptation capabilities of most organized human endeavors. Agility, as a systemic characteristic, was thus identified, and sub sequently studied to identify domain‐independent met rics, architecture, and design principles (dove, 2001).

Agility is a capability exhibited by systems and processes that enables them to sustain effective operation under conditions of unpredictability, uncertainty, and change. The value proposition of an agile SE process is risk management, appropriate when development speed and customer satisfaction are likely to be affected by requirements understandings that evolve during system development.

Common causes for requirements evolution include insufficient initial understanding, new understandings revealed during development, and evolving knowledge of the deployment environment. if ignored, requirements evo lution reduces or eliminates customer satisfaction. if unmit igated, requirements evolution causes rework and scrapped work, a principal source of time and cost overruns.

An agile system architecture incurs expense in infra structure and modularity design, which should be weighed against probabilistic costs for requirements evolution. This is risk management. The purpose of an agile SE process is to reduce the technical, cost, and schedule risks associated with accommodating benefi cial requirements evolution.

Agility is the ability to respond effectively to surprises—good or bad. Practices and techniques should be chosen for compatibility and synergy with the nature of the project (Carson, 2013; Sillitto, 2013) and the cultural environment in which they will be employed.

9.9.1 agile Se Framework

Agile SE (Forsberg et al., 2005) is summarized as follows:

• leverages an agile architecture for SE (process), enabling reconfiguration of goals, requirements, plans, and assets, predictably.

• leverages an architecture for agile SE (product), enabling changes to the product (system) during development and fabrication, predictably.

• leverages an empowered intimately involved “product owner” (chief systems engineer, customer, or equivalent responsible authority on product vision), enabling broad‐level systems thinking to inform real‐time decision making as requirements understanding evolve.

• leverages human productivity factors that affect engineering, fabrication, and customer satisfaction in an unpredictable and uncertain environment.

9.9.2 agile Metric Framework

Agility measures are enabled and constrained principally by architecture—in both the process and the product of development:

• Time to respond, measured in both the time to understand a response is necessary and the time to accomplish the response

• Cost to respond, measured in both the cost of accomplishing the response and the cost incurred elsewhere as a result of the response

• Predictability of response capability, measured before the fact in architectural preparedness for response and confirmed after the fact in repeatable accuracy of response time and cost estimates

• Scope of response capability, measured before the fact in architectural preparedness for comprehen sive response capability within mission and con firmed after the fact in repeatable evidence of broad response accommodation

9.9.3 agile architectural Framework

Agile SE and agile‐systems engineering are two differ ent things (haberfellner and de Weck, 2005) with a shared common architecture that enables the agility in each (dove, 2012). The architecture will be recognized in a simple sense as a drag‐and‐drop plug‐and‐play loosely coupled modularity, with some critical aspects not often called to mind with the general thoughts of a modular architecture.

There are three critical elements in the architecture: a roster of drag‐and‐drop encapsulated modules, a passive

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

AgilE SySTEMS EnginEEring 209

infrastructure of minimal but sufficient rules and stan dards that enable and constrain plug‐and‐play operation, and an active infrastructure that designates specific responsibilities that sustain agile operational capability:

• Modules—Modules are self‐contained encapsu lated units complete with well‐defined interfaces that conform to the plug‐and‐play passive infra structure. They can be dragged and dropped into a system of response capability with relationship to other modules determined by the passive infrastruc ture. Modules are encapsulated so that their inter faces conform to the passive infrastructure, but their methods of functionality are not dependent on the functional methods of other modules except as the passive infrastructure dictates.

• Passive infrastructure—The passive infrastructure provides drag‐and‐drop connectivity between mod ules. its value is in isolating the encapsulated mod ules so that unexpected side effects are minimized and new operational functionality is rapid. Selecting passive infrastructure elements is a critical balance between requisite variety and parsimony—just enough in standards and rules to facilitate module connectivity but not so much to overly constrain innovative system configurations.

• Active infrastructure—An agile system is not something designed and deployed in a fixed event and then left alone. Agility is most active as new system configurations are assembled in response to new requirements—something which may happen very frequently, even daily in some cases. in order for new configurations to be enabled when needed, four responsibilities are required: the collection of available modules must evolve to be always what is needed, the modules that are available must always be in deployable condition, the assembly of new configurations must be accomplished, and both the passive infrastructure and active infrastructure must have evolved when new configurations require new standards and rules. responsibilities for these four activities must be designated and embedded within the system to ensure that effective response capa bility is possible at unpredictable times:

– Module mix—Who (or what process) is respon sible for ensuring that new modules are added to the roster and existing modules are upgraded in time to satisfy response needs?

– Module readiness—Who (or what process) is responsible for ensuring that sufficient modules are ready for deployment at unpredictable times?

– System assembly—Who (or what process) assem bles new system configurations when new situa tions require something different in capability?

– infrastructure evolution—Who (or what process) is responsible for evolving the passive and active infrastructures as new rules and standards are anticipated and become appropriate?

9.9.4 agile architectural design Principles

Ten reusable, reconfigurable, scalable design principles are briefly itemized in this section:

reusable principles are as follows:

• Encapsulated modules—Modules are distinct, sep arable, loosely coupled, independent units cooper ating toward a shared common purpose.

• Facilitated interfacing (plug compatibility)— Modules share well‐defined interaction and inter face standards and are easily inserted or removed in system configurations.

• Facilitated reuse—Modules are reusable and repli cable, with supporting facilitation for finding and employing appropriate modules.

reconfigurable principles are as follows:

• Peer–peer interaction—Modules communicate directly on a peer‐to‐peer relationship; and parallel rather than sequential relationships are favored.

• Distributed control and information—Modules are directed by objective rather than method; decisions are made at point of maximum knowledge, and information is associated locally and accessible globally.

• Deferred commitment—requirements can change rapidly and continue to evolve. Work activity, response assembly, and response deployment that are deferred to the last responsible moment avoid costly wasted effort that may also preclude a subsequent effective response.

• Self‐organization—Module relationships are self‐ determined where possible, and module interaction is self‐adjusting or self‐negotiated.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .

210 CroSS‐CuTTing SySTEMS EnginEEring METhodS

Scalable principles are as follows:

• Evolving standards—Passive infrastructure stan dardizes intermodule communication and interac tion, defines module compatibility, and is evolved by designated responsibility for maintaining current and emerging relevance.

• Redundancy and diversity—duplicate modules provide capacity right‐sizing options and fail‐soft tolerance, and diversity among similar modules employing different methods is exploitable.

• Elastic capacity—Modules may be combined in responsive assemblies to increase or decrease functional capacity within the current architecture.

C op

yr ig

ht ©

2 01

5. W

ile y.

A ll

rig ht

s re

se rv

ed .