System engineering statics, Study notes of Systems Engineering

Download System engineering statics and more Study notes Systems Engineering in PDF only on Docsity!

Introduction Systems Engineering Fundamentals

i

SYSTEMS

ENGINEERING

FUNDAMENTALS

January 2001

SUPPLEMENTARY TEXT

PREPARED BY THE

DEFENSE ACQUISITION UNIVERSITY PRESS

FORT BELVOIR, VIRGINIA 22060-

Systems Engineering Fundamentals Introduction

ii

Systems Engineering Fundamentals Introduction

iv

PREFACE

This book provides a basic, conceptual-level description of engineering management disciplines that relate to the development and life cycle management of a system. For the non-engineer it provides an overview of how a system is developed. For the engineer and project manager it provides a basic framework for planning and assessing system development.

Information in the book is from various sources, but a good portion is taken from lecture material devel- oped for the two Systems Planning, Research, Development, and Engineering courses offered by the Defense Acquisition University.

The book is divided into four parts: Introduction; Systems Engineering Process; Systems Analysis and Control; and Planning, Organizing, and Managing. The first part introduces the basic concepts that govern the systems engineering process and how those concepts fit the Department of Defense acquisition process. Chapter 1 establishes the basic concept and introduces terms that will be used throughout the book. The second chapter goes through a typical acquisition life cycle showing how systems engineering supports acquisition decision making.

The second part introduces the systems engineering problem-solving process, and discusses in basic terms some traditional techniques used in the process. An overview is given, and then the process of requirements analysis, functional analysis and allocation, design synthesis, and verification is explained in some detail. This part ends with a discussion of the documentation developed as the finished output of the systems engineering process.

Part three discusses analysis and control tools that provide balance to the process. Key activities (such as risk management, configuration management, and trade studies) that support and run parallel to the system engineering process are identified and explained.

Part four discusses issues integral to the conduct of a systems engineering effort, from planning to consideration of broader management issues.

In some chapters supplementary sections provide related material that shows common techniques or policy-driven processes. These expand the basic conceptual discussion, but give the student a clearer picture of what systems engineering means in a real acquisition environment.

Chapter 1 Introduction to Systems Engineering

PART 1

INTRODUCTION

Chapter 1 Introduction to Systems Engineering

CHAPTER 1

INTRODUCTION TO

SYSTEMS ENGINEERING

MANAGEMENT

1.1 PURPOSE

The overall organization of this text is described in the Preface. This chapter establishes some of the basic premises that are expanded throughout the book. Basic terms explained in this chapter are the foundation for following definitions. Key sys- tems engineering ideas and viewpoints are pre- sented, starting with a definition of a system.

1.2 DEFINITIONS

A System Is …

Simply stated, a system is an integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective.

Systems Engineering Is…

Systems engineering consists of two significant disciplines: the technical knowledge domain in which the systems engineer operates, and systems engineering management. This book focuses on the process of systems engineering management.

Three commonly used definitions of systems engineering are provided by the best known tech- nical standards that apply to this subject. They all have a common theme:

- A logical sequence of activities and decisions that transforms an operational need into a de- scription of system performance parameters and a preferred system configuration. (MIL-STD-

499A, Engineering Management , 1 May 1974. Now cancelled.)

- An interdisciplinary approach that encompasses the entire technical effort, and evolves into and verifies an integrated and life cycle balanced set of system people, products, and process solu- tions that satisfy customer needs. (EIA Standard IS-632, Systems Engineering , December 1994.) - An interdisciplinary, collaborative approach that derives, evolves, and verifies a life-cycle bal- anced system solution which satisfies customer expectations and meets public acceptability. (IEEE P1220, Standard for Application and Management of the Systems Engineering Process , [Final Draft], 26 September 1994.)

In summary, systems engineering is an interdisci- plinary engineering management process that evolves and verifies an integrated, life-cycle bal- anced set of system solutions that satisfy customer needs.

Systems Engineering Management Is…

As illustrated by Figure 1-1, systems engineering management is accomplished by integrating three major activities:

• Development phasing that controls the design process and provides baselines that coordinate design efforts,
• A systems engineering process that provides a structure for solving design problems and

Systems Engineering Fundamentals Chapter 1

Figure 1-1. Three Activities of Systems Engineering Management

Development Phasing

Baselines

Life Cycle Planning

Systems Engineering Process

Life Cycle Integration

Systems Engineering Management

Integrated Teaming

tracking requirements flow through the design effort, and

• Life cycle integration that involves customers in the design process and ensures that the system developed is viable throughout its life.

Each one of these activities is necessary to achieve proper management of a development effort. Phas- ing has two major purposes: it controls the design effort and is the major connection between the tech- nical management effort and the overall acquisi- tion effort. It controls the design effort by devel- oping design baselines that govern each level of development. It interfaces with acquisition man- agement by providing key events in the develop- ment process, where design viability can be as- sessed. The viability of the baselines developed is a major input for acquisition management Mile- stone (MS) decisions. As a result, the timing and coordination between technical development phasing and the acquisition schedule is critical to maintain a healthy acquisition program.

The systems engineering process is the heart of systems engineering management. Its purpose is to provide a structured but flexible process that transforms requirements into specifications, archi- tectures, and configuration baselines. The disci- pline of this process provides the control and trace- ability to develop solutions that meet customer needs. The systems engineering process may be repeated one or more times during any phase of the development process.

Life cycle integration is necessary to ensure that the design solution is viable throughout the life of the system. It includes the planning associated with product and process development, as well as the integration of multiple functional concerns into the design and engineering process. In this manner, product cycle-times can be reduced, and the need for redesign and rework substantially reduced.

1.3 DEVELOPMENT PHASING

Development usually progresses through distinct levels or stages:

Systems Engineering Fundamentals Chapter 1

Figure 1-3. The Systems Engineering Process

solving process, applied sequentially through all stages of development, that is used to:

- Transform needs and requirements into a set of system product and process descriptions (add- ing value and more detail with each level of development),

• Generate information for decision makers, and
• Provide input for the next level of development.

As illustrated by Figure 1-3, the fundamental sys- tems engineering activities are Requirements Analysis, Functional Analysis and Allocation, and Design Synthesis—all balanced by techniques and tools collectively called System Analysis and Con- trol. Systems engineering controls are used to track decisions and requirements, maintain technical baselines, manage interfaces, manage risks, track cost and schedule, track technical performance, verify requirements are met, and review/audit the progress.

During the systems engineering process architec- tures are generated to better describe and under- stand the system. The word “architecture” is used in various contexts in the general field of engi- neering. It is used as a general description of how the subsystems join together to form the system. It can also be a detailed description of an aspect of a system: for example, the Operational, System, and Technical Architectures used in Command, Con- trol, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR), and software intensive developments. However, Sys- tems Engineering Management as developed in DoD recognizes three universally usable architec- tures that describe important aspects of the system: functional, physical, and system architectures. This book will focus on these architectures as neces- sary components of the systems engineering process.

The Functional Architecture identifies and struc- tures the allocated functional and performance requirements. The Physical Architecture depicts the

PROCESS OUTPUT

P R O C E S S I N P U T

Requirements Analysis

Requirements Loop

Verification

Design Loop

Functional Analysis and Allocation

Design Synthesis

System Analysis and Control (Balance)

Chapter 1 Introduction to Systems Engineering

system product by showing how it is broken down into subsystems and components. The System Architecture identifies all the products (including enabling products) that are necessary to support the system and, by implication, the processes necessary for development, production/construc- tion, deployment, operations, support, disposal, training, and verification.

Life Cycle Integration

Life cycle integration is achieved through inte- grated development—that is, concurrent consid- eration of all life cycle needs during the develop- ment process. DoD policy requires integrated development, called Integrated Product and Prod- uct Development (IPPD) in DoD, to be practiced at all levels in the acquisition chain of command as will be explained in the chapter on IPPD. Con- current consideration of all life cycle needs can be greatly enhanced through the use of interdiscipli- nary teams. These teams are often referred to as Integrated Product Teams (IPTs).

The objective of an Integrated Product Team is to:

• Produce a design solution that satisfies initially defined requirements, and
• Communicate that design solution clearly, effectively, and in a timely manner.

Multi-functional, integrated teams:

• Place balanced emphasis on product and process development, and
• Require early involvement of all disciplines appropriate to the team task.

Design-level IPT members are chosen to meet the team objectives and generally have distinctive com- petence in:

• Technical management (systems engineering),
• Life cycle functional areas (eight primary functions), - Technical specialty areas, such as safety, risk management, quality, etc., or - When appropriate, business areas such as finance, cost/budget analysis, and contracting.

Life Cycle Functions

Life cycle functions are the characteristic actions associated with the system life cycle. As illustrated by Figure 1-4, they are development, production and construction, deployment (fielding), opera- tion, support, disposal, training, and verification. These activities cover the “cradle to grave” life cycle process and are associated with major func- tional groups that provide essential support to the life cycle process. These key life cycle functions are commonly referred to as the eight primary functions of systems engineering.

The customers of the systems engineer perform the life-cycle functions. The system user’s needs are emphasized because their needs generate the requirement for the system, but it must be remem- bered that all of the life-cycle functional areas generate requirements for the systems engineer- ing process once the user has established the basic need. Those that perform the primary functions also provide life-cycle representation in design- level integrated teams.

Primary Function Definitions

Development includes the activities required to evolve the system from customer needs to product or process solutions.

Manufacturing/Production/Construction in- cludes the fabrication of engineering test models and “brass boards,” low rate initial production, full-rate production of systems and end items, or the construction of large or unique systems or sub- systems.

Deployment (Fielding) includes the activities nec- essary to initially deliver, transport, receive, pro- cess, assemble, install, checkout, train, operate, house, store, or field the system to achieve full operational capability.

Chapter 1 Introduction to Systems Engineering

• Development of a system that can be produced economically and supported throughout the life cycle,
• Development and monitoring of internal and external interface compatibility of the sys- tem and subsystems using an open systems approach,
• Establishment of baselines and configuration control, and
• Proper focus and structure for system and major sub-system level design IPTs.

1.5 GUIDANCE

DoD 5000.2-R establishes two fundamental requirements for program management:

• It requires that an Integrated Product and Process approach be taken to design wherever practicable, and
• It requires that a disciplined systems engineer- ing process be used to translate operational needs and/or requirements into a system solution.

Tailoring the Process

System engineering is applied during all acquisi- tion and support phases for large- and small-scale systems, new developments or product improve- ments, and single and multiple procurements. The process must be tailored for different needs and/or requirements. Tailoring considerations include system size and complexity, level of system definition detail, scenarios and missions, con- straints and requirements, technology base, major risk factors, and organizational best practices and strengths.

For example, systems engineering of software should follow the basic systems engineering approach as presented in this book. However, it must be tailored to accommodate the software development environment, and the unique progress

tracking and verification problems software devel- opment entails. In a like manner, all technology domains are expected to bring their own unique needs to the process.

This book provides a conceptual-level description of systems engineering management. The specific techniques, nomenclature, and recommended methods are not meant to be prescriptive. Techni- cal managers must tailor their systems engineer- ing planning to meet their particular requirements and constraints, environment, technical domain, and schedule/budget situation.

However, the basic time-proven concepts inherent in the systems engineering approach must be re- tained to provide continuity and control. For com- plex system designs, a full and documented un- derstanding of what the system must do should precede development of component performance descriptions, which should precede component detail descriptions. Though some parts of the sys- tem may be dictated as a constraint or interface, in general, solving the design problem should start with analyzing the requirements and determining what the system has to do before physical alterna- tives are chosen. Configurations must be controlled and risk must be managed.

Tailoring of this process has to be done carefully to avoid the introduction of substantial unseen risk and uncertainty. Without the control, coordination, and traceability of systems engineering, an envi- ronment of uncertainty results which will lead to surprises. Experience has shown that these surprises almost invariably lead to significant impacts to cost and schedule. Tailored processes that reflect the general conceptual approach of this book have been developed and adopted by profes- sional societies, academia, industry associations, government agencies, and major companies.

1.6 SUMMARY POINTS

• Systems engineering management is a multi- functional process that integrates life cycle functions, the systems engineering problem- solving process, and progressive baselining.

Systems Engineering Fundamentals Chapter 1

• The systems engineering process is a prob- lem-solving process that drives the balanced development of system products and processes.
• Integrated Product Teams should apply the sys- tems engineering process to develop a life cycle balanced-design solution.
• The systems engineering process is applied to each level of development, one level at a time.
• Fundamental systems engineering activities are Requirements Analysis, Functional Analysis/ Allocation, and Design Synthesis, all of which are balanced by System Analysis and Control. - Baseline phasing provides for an increasing level of descriptive detail of the products and processes with each application of the systems engineering process. - Baselining in a nut shell is a concept descrip- tion that leads to a system definition which, in turn, leads to component definitions, and then to component designs, which finally lead to a product. - The output of each application of the systems engineering process is a major input to the next process application.

Systems Engineering Fundamentals Chapter 2

Figure 2-1. Revised DoD 5000 Acquisition Process

defined by a series of phases during which tech- nology is defined and matured into viable concepts, which are subsequently developed and readied for production, after which the systems produced are supported in the field.

The process allows for a given system to enter the process at any of the development phases. For ex- ample, a system using unproven technology would enter at the beginning stages of the process and would proceed through a lengthy period of tech- nology maturation, while a system based on ma- ture and proven technologies might enter directly into engineering development or, conceivably, even production. The process itself (Figure 2-1) includes four phases of development. The first, Concept and Technology Development , is intended to ex- plore alternative concepts based on assessments of operational needs, technology readiness, risk, and affordability. Entry into this phase does not imply that DoD has committed to a new acquisi- tion program; rather, it is the initiation of a pro- cess to determine whether or not a need (typically described in a Mission Need Statement (MNS)) can be met at reasonable levels of technical risk and at affordable costs. The decision to enter into

the Concept and Technology Development phase is made formally at the Milestone A forum.

The Concept and Technology Development phase begins with concept exploration. During this stage, concept studies are undertaken to define al- ternative concepts and to provide information about capability and risk that would permit an objective comparison of competing concepts. A decision review is held after completion of the concept ex- ploration activities. The purpose of this review is to determine whether further technology develop- ment is required, or whether the system is ready to enter into system acquisition. If the key technolo- gies involved are reasonably mature and have al- ready been demonstrated, the Milestone Decision Authority (MDA) may agree to allow the system to proceed into system acquisition; if not, the sys- tem may be directed into a component advanced development stage. (See Supplement A to this chapter for a definition of Technology Readiness levels.) During this stage, system architecture defi- nition will continue and key technologies will be demonstrated in order to ensure that technical and cost risks are understood and are at acceptable lev- els prior to entering acquisition. In any event, the

Milestones

- Process entry at Milestones A, B, or C **(or within phases)

• Program outyear funding** when it makes sense, but no later than Milestone B

Concept and Technology Development

System Development and Demonstration

Production and Deployment

Sustainment and Disposal Pre-Systems Acquisition

Systems Acquisition (Engineering Development, Demonstration, LRIP and Production)

Sustainment and Maintenance

Relationship to Requirements Process

MNS ORD

A B C IOC

Single Step or Evolution to Full Capacity

All validated by JROC

Chapter 2 Systems Engineering Management in DoD Acquisition

Concept and Technology Development phase ends with a defined system architecture supported by technologies that are at acceptable levels of matu- rity to justify entry into system acquisition.

Formal system acquisition begins with a Milestone B decision. The decision is based on an integrated assessment of technology maturity, user require- ments, and funding. A successful Milestone B is followed by the System Development and Dem- onstration phase. This phase could be entered di- rectly as a result of a technological opportunity and urgent user need, as well as having come through concept and technology development. The System Development and Demonstration phase consists of two stages of development, system integration and system demonstration. Depending upon the maturity level of the system, it could enter at either stage, or the stages could be combined. This is the phase during which the technologies, components and subsystems defined earlier are first integrated at the system level, and then demon- strated and tested. If the system has never been integrated into a complete system, it will enter this phase at the system integration stage. When sub- systems have been integrated, prototypes demon- strated, and risks are considered acceptable, the program will normally enter the system demon- stration stage following an interim review by the MDA to ensure readiness. The system demonstra- tion stage is intended to demonstrate that the system has operational utility consistent with the opera- tional requirements. Engineering demonstration models are developed and system level develop- ment testing and operational assessments are per- formed to ensure that the system performs as required. These demonstrations are to be conducted in environments that represent the eventual opera- tional environments intended. Once a system has been demonstrated in an operationally relevant environment, it may enter the Production and Deployment phase.

The Production and Deployment phase consists of two stages: production readiness and low rate initial production (LRIP), and rate production and deployment. The decision forum for entry into this phase is the Milestone C event. Again, the fundamental issue as to where a program enters

the process is a function of technology maturity, so the possibility exists that a system could enter directly into this phase if it were sufficiently ma- ture, for example, a commercial product to be pro- duced for defense applications. However the entry is made—directly or through the maturation pro- cess described, the production readiness and LRIP stage is where initial operational test, live fire test, and low rate initial production are conducted. Upon completion of the LRIP stage and following a favorable Beyond LRIP test report, the system enters the rate production and deployment stage during which the item is produced and deployed to the user. As the system is produced and deployed, the final phase, Sustainment and Disposal, begins.

The last, and longest, phase is the Sustainment and Disposal phase of the program. During this phase all necessary activities are accomplished to maintain and sustain the system in the field in the most cost-effective manner possible. The scope of activities is broad and includes everything from maintenance and supply to safety, health, and en- vironmental management. This period may also include transition from contractor to organic sup- port, if appropriate. During this phase, modifica- tions and product improvements are usually imple- mented to update and maintain the required levels of operational capability as technologies and threat systems evolve. At the end of the system service life it is disposed of in accordance with applicable classified and environmental laws, regulations, and directives. Disposal activities also include recy- cling, material recovery, salvage of reutilization, and disposal of by-products from development and production.

The key to this model of the acquisition process is that programs have the flexibility to enter at any of the first three phases described. The decision as to where the program should enter the process is primarily a function of user needs and technology maturity. The MDA makes the decision for the program in question. Program managers are encouraged to work with their users to develop evo- lutionary acquisition strategies that will permit deliveries of usable capabilities in as short a time- frame as possible, with improvements and en- hancements added as needed through continuing

Chapter 2 Systems Engineering Management in DoD Acquisition

Figure 2-3. Concept and Technology Development (Component Advanced Development Stage)

expected to employ various techniques including the systems engineering process that translates inputs into viable concept architectures whose functionality can be traced to the requirements. In addition, market surveys, Business Process Reengi- neering activities, operational analysis, and trade studies support the process.

The primary inputs to these activities include requirements, in form of the MNS, assessments of technology opportunities and status, and the out- puts from any efforts undertaken to explore poten- tial solutions. When the contractor studies are complete, a specific concept to be pursued is selected based on a integrated assessment of tech- nical performance; technical, schedule and cost risk; as well as other relevant factors. A decision review is then held to evaluate the concept recom- mended and the state of technology upon which the concept depends. The MDA then makes a decision as to whether the concept development work needs to be extended or redirected, or whether the technology maturity is such that the program can proceed directly to either Mile-stone B (System Development and Demonstration) or Milestone C (Production and Deployment).

If the details of the concept require definition, i.e., the system has yet to be designed and demon- strated previously, or the system appears to be based on technologies that hold significant risk, then it is likely that the system will proceed to the second stage of the Concept and Technology Development phase. This stage, Component Advanced Development , is represented in Figure 2-3. This is also a pre-acquisition stage of devel- opment and is usually characterized by extensive involvement of the DoD Science and Technology (S&T) community. The fundamental objectives of this stage of development are to define a system- level architecture and to accomplish risk-reduction activities as required to establish confidence that the building blocks of the system are sufficiently well-defined, tested and demonstrated to provide confidence that, when integrated into higher level assemblies and subsystems, they will perform reliably.

Development of a system-level architecture entails continuing refinement of system level requirements based on comparative analyses of the system con- cepts under consideration. It also requires that consideration be given to the role that the system

Continued Concept Exploration Activities As Appropriate

Advanced Concept Technology Demonstration

Systems Engineering Process (System Architecture Developed)

System Architecture Developed Component Technology Demonstrated

ORD Development (^) MS B

Concept

Decision Review

Systems Engineering Fundamentals Chapter 2

will play in the system of systems of which it will be a part. System level interfaces must be estab- lished. Communications and interoperability re- quirements must be established, data flows defined, and operational concepts refined. Top level plan- ning should also address the strategies that will be employed to maintain the supportability and affordability of the system over its life cycle including the use of common interface standards and open systems architectures. Important design requirements such as interoperability, open sys- tems, and the use of commercial components should also be addressed during this stage of the program.

Risk reduction activities such as modeling and simulation, component testing, bench testing, and man-in-the-loop testing are emphasized as deci- sions are made regarding the various technologies that must be integrated to form the system. The primary focus at this stage is to ensure that the key technologies that represent the system components (assemblies and sub-systems) are well understood

and are mature enough to justify their use in a sys- tem design and development effort. The next stage of the life cycle involves engineering development, so research and development (R&D) activities conducted within the science and technology appropriations should be completed during this stage.

System Development and Demonstration

The decision forum for entry into the System Development and Demonstration (SD&D) phase is the Milestone B event. Entry into this phase rep- resents program initiation , the formal beginning of a system acquisition effort. This is the govern- ment commitment to pursue the program. Entry requires mature technology, validated require- ments, and funding. At this point, the program re- quirement must be defined by an Operational Re- quirements Document (ORD). This phase consists of two primary stages, system integration (Figure 2-4) and system demonstration (Figure 2-5).

Figure 2-4. System Development and Demonstration (System Integration Stage)

MS B

System Level Architecture

ORD

Previous Phase

Tech Review

Requirements Review Prototype Demonstration System Definition Effort

IPR

Draft Allocated Baseline

Preliminary and Detail Design Efforts

Approved Functional Baseline

Preliminary Design Effort

RequirementsAnalysis RequirementsLoop

Verification

DesignLoop

Functional Analysisand Allocation

Design Synthesis

System Analysisand Control (Balance)