ENG 101

Sect 1

Job View - Systems Engineering is what a person with the titled position of "Systems Engineer" does and has as his/her job description, responsibility and/or role Role

For example, a paper published in the International Council of Systems Engineers (INCOSE) 1996 Proceedings identified 12 different job roles, based on a variety of surveys that could be considered to constitute Systems Engineering. These job roles included: Requirements Owner, System Designer, System Analyst, Test Engineer, Logistics and Operations, System Integrator, Customer Interface, Technical Manager, Information Manager, Process Engineer, Coordinator, and miscellaneous Software Engineering roles. .

•Organizational View - Systems Engineering is what an organization named "Systems Engineering" does and has as its responsibility and/or role.

•Problem-Solving View - Systems Engineering is a way of thinking about any complex technical problem.

•Multidisciplinary View - Systems Engineering is a multidisciplinary approach that defines the total technical effort needed to realize system products and sustain their life cycle services.

Systems Engineering is an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and total life cycle-balanced set of system, people and process solutions that satisfy customer needs.

The Acquirer: DoD program offices and agencies mainly use Systems Engineering processes and tools to manage development activities.

•The Developer: The defense industry mainly uses Systems Engineering processes and tools as part of their approach both to manage development, as well as to create products for the acquirer.

While there are many complex issues that contribute to program problems, systemic problems related to Systems Engineering identified by the GAO include:

•Requirements turbulence

•Poor requirements management

•Use of immature technologies

•Inadequate technical assessment Technical Assessment

A key part of the Technical Assessment process is the use of the results of Technical Design Reviews. Such reviews and the assessments that result from them are one of the keys to a knowledge-based acquisition process. A recent GAO survey of over 70 major DoD programs concluded that:

The absence of a knowledge-based acquisition process steeped in disciplined Systems Engineering practices contributes greatly to DoD’s poor acquisition outcomes. Systems Engineering is a process that translates customer wants into specific product features for which requisite technological, software, engineering and production capabilities can be identified….DoD programs often do not conduct Systems Engineering in a timely fashion…or in some cases, omit key Systems Engineering activities altogether. •Unstable/unproven product designs

•Premature entry into production

•Undisciplined software development

•Lack of Robust Systems Engineering

Systems Engineering: Is an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and total life cycle-balanced set of system, people and process solutions that satisfy customer needs.

The Scope of Systems Engineering: Includes transformation of needed operational capabilities into an integrated system design; integration of technical life cycle efforts; and development of technical information to support program management decision-making. Systems Engineering, because it encompasses the entire technical effort, is a key enabler of effective Total Life Cycle System Management (TLCSM).

Challenges to Systems Engineering: Include growing system complexity; workforce turbulence; low technical management investment; inconsistent application of Systems Engineering; insufficient early use of Systems Engineering; and poor initial program formulation, insufficient tools and environments and inconsistent requirements management.

processProcess

1.3

A process is a sequence of steps or activities performed for a given purpose. A process converts an input (such as requirements) to a desired output (such as defined work products) through a set of structured activities. To execute a process, it takes resources such as trained people, funds, facilities, equipment, tools and methods. Processes are constrained by various management and legal and regulatory directives and requirements. identifies "what" has to be done but not the details of "how" to do it. Standardized processes are essential for:

•Clarity in communicating taskings

•Controlling the overall technical effort

•Designing systems solutions

•'Realizing' products that make up the system

"Realization" is a formal term used to precisely quantify the desired end-state of Systems Engineering activities.

A formal definition of "realization" from a Systems Engineering perspective is shown here.

The correct statements are "Transitioning the product, ultimately to the customer", "Providing the physical design solution in an appropriate form" and "Verifying and validating the product".

Which of the following statements about the various Technical Processes used in Systems Engineering is correct? They are used for designing systems and for product realization.

Which of the following statements about the various Technical Management Processes used in Systems Engineering is correct? They are key to managing the overall technical effort.

Let's look at a simplistic (you'll find out why later!) example of Systems Engineering Technical Processes in action, starting with the three Technical Processes used to design a system. These processes are:

1.Stakeholder Requirements Definition Process : Requirements for DoD systems come from various diverse constituencies (generically categorized as Acquirer Requirements Acquirer Requirements

Acquirer Requirements may be in the form of requirement statements from a customer, user or operator; or be expressed as a set of assigned/allocated specifications developed previously. and Other Interested Party Requirements Other Interested Party Requirements

These types of requirements include those of parties who have some interest in the system, such as those providing life cycle support functions; OSD management or other government agencies; and laws, regulations, treaties, policies, etc. which may affect the program or project. ). Together these requirements comprise the set of Stakeholder RequirementsStakeholder requirements

These are requirements that represent what stakeholders of a system need or expect of the system products. They are comprised of "Acquirer Requirements" and "Other Interested Party Requirements". , which also include Derived Requirements Derived Requirements

Derived Requirements are those that are not explicitly stated in the set of Stakeholder Requirements, yet are required to satisfy one or more specific Stakeholder Requirements. Derived Requirements are generated based on an operational or technical analysis of a Stakeholder Requirement in order to clarify the requirement or make it achievable. For example:

Stakeholder Requirement: A missile must have a fly-out distance of 2 kms and hit a target having a Radar Cross Section the size of a tennis ball.

Derived Requirement: The missile shall be aimed within 2 degrees of the target so that the warhead terminal seeker can lock on and perform the terminal intercept. . These sets of requirements are ultimately transformed into Technical Requirements Technical Requirements

A Technical Requirement is derived from analysis of Stakeholder Requirements. It is expressed as a confirmed and quantitative "shall" statement. The set of Technical Requirements are inputs to the Requirements Analysis Process. Technical Requirements establish the basis for system development. . The latter ultimately become the basis for the design. Key Measures of Effectiveness Measures of Effectiveness

Measures of Effectiveness (MOEs) give definition to the operational capabilities essential to mission accomplishment. They represent the metrics by which satisfaction with products produced by the technical effort will be measured. KPPs, established as part of the JCIDS process, are special cases of MOEs. Typically if a system cannot satisfy its KPPs, its development should cease. are also initially identified.

2.Requirements Analysis Process : Technical Requirements are then analyzed in various ways to determine an optimal functional architecture Functional Architecture

This is an arrangement of functions and their sub-functions and interfaces (internal and external) that defines the execution sequencing, conditions for control or data flow, and the performance requirements to satisfy the requirements baseline. . Interfaces are defined in more detail. Performance parameters are allocated. Important additional Technical Requirements (called Derived Technical RequirementsDerived Technical Requirements

These are technical requirements that are further refined from a primary source requirement or a higher-level derived requirement. Derived Technical Requirements are requirements that result from the analysis of Technical Requirements, which is done as part of the Requirements Analysis Process or Architecture Design Process. ) are identified. Work products Work Products

A work product is any artifact--material or electronic--generated during the conduct of the activities and tasks of a process, including the desired outputs. are baselined.

3.Architecture Design Process : Using the outcomes from the Stakeholder Requirements Definition Process and the Requirements Analysis Process, alternative design solutions are developed. More Derived Technical Requirements may be identified as well. These design solutions are evaluated to determine which are acceptable within cost, schedule and technical constraints. A design or a physical architecture Physical Architecture

This is a hierarchical arrangement of people, product and process solutions; their functional and performance requirements; their internal and external interfaces; and their physical constraints. It forms the basis for the design. is established.

Outcomes of the Architecture Design Process typically include a set of Solution-Specified Requirements Solution-Specified Requirements

These are the requirements that characterize and specify the functions and performance of the design solution. They are expressed in the System Specification, subsystem specifications, verification/validation criteria, various end product specifications and requirements for Enabling Products. , a key component of which is the System Specification System Specification

This is a type of program-unique specification that describes the requirements and how they will be verified for a combination of elements that must function together to produce the capabilities that fulfill a mission need, including hardware, equipment and software. . These requirements are baselined and become part of a Technical Data Package (TDP) A Technical Data Package (TDP)

A Technical Data Package (TDP) provides a comprehensive description of a given system element. The TDP is used for the Implementation Process and is retained and placed under configuration management and baselined throughout the life of the product.

Implementation Process : If subsystems do not need to be developed, then, using appropriate elements from the TDP, the product is made, bought or reused. This may involve hardware fabrication, manufacturing, software coding or purchase from outside sources. No matter what their source, some degree of low-level verification and validation is performed to make sure that 'good' products are implemented. Some supporting documentation may be developed.

5.Integration Process : At some point, implementation is completed. End product components are assembled and integrated. As part of this, integrated components are verified and validated as appropriate so as to ensure that only 'good' products actually get assembled and integrated.

6.Verification Process : Using criteria established as part of the Architecture Design Process and various plans Various Plans

Key among these plans is the Test and Evaluation Master Plan (TEMP). The TEMP, one of the outcomes of the Technical Planning Process, provides top-level details of systems-level verification (Developmental Testing) and validation (Operational Testing). Specific test scenarios and scripts are provided elsewhere in more detailed test plans. , the end product is verified. This ensures that it conforms to its 'design-to' requirements and has been "built right".

7.Validation Process : Using criteria established as part of the Architecture Design Process and various plans, the end product is validated. This ensures that it conforms to its Stakeholder Requirements and is the "right product".

8.Transition Process : The end product either: (1) moves up a level (e.g., from subsystem to system) in the physical architecture of the system for more development as needed; (2) it transitions to the next acquisition life cycle phase; or (3) the End Product is delivered successfully to the user.

Technical Control Processes . These are:

1.Requirements Management Process : Used heavily as the three design Technical Processes iterate and interact, it ensures that all of the generated Technical Requirements and Derived Requirements can ultimately be traced back to user-defined capabilities and needs.

2.Interface Management Process : Used to support the Requirements Analysis Process (where many interfaces are initially defined) as well as the Integration Process. Interface Management ensures interface definition and compliance among system elements and for interoperability with other systems.

3.Risk Management Process : Is a core process which underlies all others. It identifies, analyzes, mitigates and tracks program technical risks.

4.Configuration Management Process : Ensures that baselines Baselines

Typically these include the following: •Functional Baseline: Documentation describing system and subsystem functional characteristics and the verification required to demonstrate the achievement of those specified functional characteristics. •Allocated Baseline: Documentation that designates the Configuration Items (CIs) making up a system, and then allocates the system function and performance requirements across the CIs (hence the term 'allocated baseline'). •Product Baseline: The approved technical documentation which describes a system's Configuration Item during the production, fielding/deployment and operational support phases of its life cycle. are established, controlled and kept consistent. Configuration Management is a key player with the Requirements Management, Interface Management and Technical Data Management Processes.

5.Technical Data Management Process : A wide variety of data and information Data and Information

The term "data" as used in Technical Data Management includes technical data; computer software documentation; or representation of facts, numbers, or datum of any nature that can be communicated, stored and processed to form information required by a contract or agreement to be delivered, or accessed by, the Government.

Information, on the other hand, is generally considered as processed data. The form of the processed data is dependent on the documentation, report, review formats or templates that are applicable.

Of course, one needs wisdom to use either data or information most effectively. Unfortunately, that is not one of the by-products of Technical Data Management! is produced as outcomes of various process activities. Technical Data Management plans for it; acquires it; provides access to it; manages it; and protects data and information of a technical nature needed to support the total life cycle of a system.

Technical Planning Process : This management process is the lynchpin of the entire Systems Engineering process and ultimately, initiates the overall effort. Various key plans, such as the Systems Engineering Plan (SEP) Systems Engineering Plan (SEP)

The SEP is a "living" "go to" technical planning document and the blueprint for the conduct, management, and control of the technical aspects of the government's program from concept to disposal. While a government plan, once a contract is awarded, it is expected that the SEP will be updated to reflect the winning contractor(s)' technical strategy and System Engineering approach. , the Test and Evaluation Master Plan (TEMP) Test and Evaluation Master Plan (TEMP)

The TEMP is an important document in that it contains the required type and amount of integrated test and evaluation events, along with their resource requirements. The TEMP focuses on the overall structure, major elements and objectives of the T&E program, and it must be consistent with the Systems Engineering Plan (SEP). and various other plans Other Plans

A number of "other plans" exist. Some of them frame the actual program's implementation of Technical Management Processes. For example: Interface Management Plan; Requirements Management Plan; Risk Management Plan; Configuration Management Plan; Data Management Plan, among others. Others are so-called specialty plans which include: Electromagnetic Compatibility/ Interference (EMC/EMI) Control Plan; Human Systems Integration (HSI) Plan; Producibility Plan; Programmatic Environment, Safety, and Occupational Health Evaluation (PESHE); Security Plan; Information Support Plan; Modeling & Simulation (M&S) Plan; Corrosion Prevention Plan, etc.

Many of these plans are discussed in various sections of the Defense Acquisition Guidebook (DAG). In some cases, specific formats are suggested and in other cases, plan formats depend on local command policies and regulations. Some plans are required by statute, and details about them are provided via tabular format as enclosures to the DoD 5000-series of acquisition directives. are key outcomes of the Technical Planning Process.

7.Technical Assessment Process : This process provides visibility to 'where we are' and 'where we are going' in terms of the application of Technical Processes. Key tools used in Technical Assessment include Technical Reviews Technical Reviews

Technical Reviews are an important oversight tool. They are used to review and evaluate the state of the system and the program, re-directing activity after the review if found necessary. Technical Reviews are key decision events used to measure technical progress and maturity in system development as well as to assess various programmatic issues. , Earned Value Management (EVM) Earned Value Management (EVM)

Earned Value Management is a tool that allows visibility into contractual technical, cost, and schedule planning, performance, and progress. This visibility provides insight to contract performance, but also provides the necessary data points to statistically estimate probable completion costs. EVM helps to ensure that cost, schedule and technical aspects of the contract are truly integrated. and Technical Performance Measurement (TPM) Technical Performance Measurement (TPM)

This is the technique of predicting the future value of a key technical parameter of the higher-level end product under development, based on current assessments of products lower in the system structure. In the DoD, these key technical parameters are typically related in some way to Key Performance Parameters (KPPs) as well as Measures of Effectiveness (MOEs). .

8.Decision Analysis Process : This is a cross-cutting process that provides a rational, repeatable basis -- both formal and informal -- for evaluating and selecting alternatives when a decision must be made. It operates within the program's trade space Trade Space

Trade Space is the set of program and system parameters, attributes and characteristics required to satisfy some aspect of system performance. Decision-makers define and refine the development system by making trade-offs with regard to cost, schedule, risk and performance---all of which fall within the "trade space".

Technical Processes get applied recursively to each system element, from the top to the bottom. This continues until the lowest system products are defined to the point where they can be implemented (i.e., bought, built or reused) and realized.

Meanwhile, Technical Management Processes are controlling all these Technical Processes and ensuring their effective application.

There are eight Technical Processes that are used for designing and realizing systems.

Systems Engineering Technical Processes for designing systems include:

1.Stakeholder Requirements Definition: Translates stakeholder needs into Technical Requirements

2.Requirements Analysis: Improves understanding of requirements and their functional relationships

3.Architecture Design: Develops alternative design solutions, physical architectures and selects a final design (Solution-Specified Requirements)

Systems Engineering Technical Processes for realizing systems products include:

1.Implementation: Creates (making, buying or reusing) low-level system elements

2.Integration: Incorporates lower-level system elements into higher-level ones

3.Verification: Confirms that system elements meet design-to or build-to specifications

4.Validation: Confirms that system elements meet Stakeholder Requirements

5.Transition: Moves a system element to the next development stage or, for the End Product, to the user

Systems Engineering Technical Management Processes are used to control the application of the Technical Processes and to help ensure that they're effectively used. The eight Technical Management Processes are:

1.Technical Planning: Ensures the proper application of Systems Engineering processes

2.Requirements Management: Provides traceability of system and subsystem requirements, ultimately back to user-defined capabilities and needs

3.Interface Management: Ensures interface definition and compliance among system elements, including other systems

4.Risk Management: Examines the technical risk of deviating from program plans

5.Configuration Management: Establishes and maintains the consistency of a product's attributes with its requirements and configuration information

6.Technical Data Management: Plans for, acquires, accesses, manages, protects and uses data of a technical nature in order to support the total life cycle of a system

7.Technical Assessment: Measures technical progress and the effectiveness of plans and requirements

8.Decision Analysis: Provides the basis for evaluation and selection of technical alternatives when decisions need to be made

1.4

Additionally, standards play key roles in the following areas:

•They provide a baseline of the "what's" and "why's". This provides a basis for assessing and improving an organization's policies and procedures.

•They are used by developers Developers

Although the 'developer' is cited here as reflective of the defense industry, in some situations, the DoD is both the 'acquirer' and the 'developer'. to:

◦Establish and standardize internal processes

◦Direct usage by suppliers and subcontractors

◦Assess internal and supplier capabilities

◦Develop Systems Engineering technical plans

•They are used by acquirers to:

◦Understand the developer's Systems Engineering activities

◦Determine and assess developer capabilities

•They are used by countries to: Provide an industry segment with a set of national practices.

NOTE: DoD acquirers need to be familiar with standards that developers may use. This is so they can properly evaluate the developer's proposals relative to Systems Engineering submitted as part of the contracting process. However, the DoD does not generally contractually impose any particular SE standard on developers.

These Systems Engineering standards differ primarily in their depth and breadth of coverage.

•ISO/IEC 15288 (which is identical to IEEE Std 15288) has the greatest breadth (25 system life cycle processes including post-deployment ones) but the least depth of coverage. It is useful for top-level planning, primarily at the organizational level. This standard is designed to be used by an organization, a project within an organization, or an acquirer and a supplier via an appropriate agreement.

•EIA 632 defines the set of requirements for engineering a system. The processes in EIA 632 describe 'what to do' with respect to the processes for engineering a system. These are at the next level down from the ISO/IEC 15288 level of system life cycle processes.

•IEEE 1220 defines a Systems Engineering process. It gives the next level of detail below the process requirements described in EIA 632. The process is described more at the task or application level.

IEEE 1220 has the greatest depth of coverage for its limited scope but the least breadth. EIA-632 falls between the other two standards.

Key commercial Systems Engineering standards include _____. EIA 632, IEEE 1220 and ISO/IEC 15288

The scope, breadth and life cycle applicability of the various Systems Engineering commercial standards such as EIA 632, IEEE 1220 and ISO/IEC 15288 are consistent. False

Standards vs. Maturity Models

Standards are by design useful for helping a project implement Systems Engineering. They provide a set of processes that, if performed by qualified persons using appropriate tools and methods, will provide a capability for effective and efficient engineering of systems.

Maturity models (e.g., the CMMI) are by intent useful for determining the capability and/or maturity of an organization to perform Systems Engineering. A maturity model is used to assess, from an organizational perspective, how well processes have been established and instituted and how well they are being followed.

1.5

Broad categories of system models include:

1.A generic dictionary type of definition that provides some insight but limited usefulness for actually engineering a particular system

2.A definition that considers the system as the operational entity

3.A definition encompassing both operational products and related enabling (life cycle support services) products

The notion behind this system model is that every system consists of:

1.One or more End Products that will perform the intended operational functions expected by the customer and be within the constraints set by other stakeholders

2.A set of Enabling Products that perform life cycle service functions required for the End Product to operate effectively

Each End Product will have its unique and common set of Enabling Products that will enable the End Product to be designed, realized, deployed, operated, maintained and, when the End Product has finished its useful life, to be properly disposed.

Enabling Products also include training products that will enable the operators and maintainers of the system to perform their missions.

End Products and Enabling Products can be further characterized as outlined below.

•End Product :

◦Defined by a customer need

◦Performs the operational functions required by a customer

◦Has '-ilities' designed in - Producibility, Testability, Trainability, Supportability,

Disposability, etc.

•Enabling Product :

◦Defined as those products required to enable the End Product to be developed, produced, tested, deployed, utilized, supported and disposed of

◦May need to be developed or may already exist and thus constrain Constrain

For instance, the size and operation of nozzles and clamping devices used for air-to-air refueling have been standardized over many years within the Air Force and Navy tanker fleets. Existing aircraft use these nozzles and clamping designs. New aircraft must accommodate them as well. Similar considerations regarding so-called Ground Handling Equipment (GHE), used to service aircraft, may apply as well. the End Product

◦Each End Product has its own set of Enabling Products

◦Enabling Products are determined by End Product life cycle requirements

◦Must be available to support End Product life cycle functions

An End Product can be:

1.Self-contained in terms of its use and operations

Examples: An aircraft, a tank, a submarine, a communications module or a satellite

2.Items that have no use outside a larger end product, but that are developed as an end product of a subsystem

Examples: An engine or radio for an aircraft; a power train or braking system for a tank; switches or transducers for a communications module; a solar panel or transmitter for a satellite

Enabling Products perform non-operational functions of the system. Some examples include:

•Development Plans and schedules; engineering policies and procedures; automated tools; models; qualified engineering and management personnel

•Manufacturing Policies and procedures; manufacturing facilities; jigs, special tools and equipment; production processes; manufacturing and procurement personnel

•Test Test plans, policies and procedures; models and mockups; special tools and test equipment; test facilities and sites; simulation or analytical models; inspection procedures and test personnel

continue with examples of generic Enabling Products:

•Operations/Deployment: Plans, policies and procedures; packaging materials; storage facilities; special handling and transportation equipment; installation procedures and environmental permits; deployment instructions; and installation personnel

•Training/Utilization: Plans and schedules; simulators and training models; courses and materials; special training facilities, ranges and trainers

•Support: Policies and procedures; tools and repair equipment; support facilities and handling equipment; maintenance manuals; maintenance management systems; special diagnostic equipment; repair personnel

•Retirement: Plans, schedules and procedures; refurbishment facilities; environmental permits and disposal sites; equipment for disposal/recycling of spent products; qualified disposal personnel

Planning and managing the Systems Engineering effort by:

◦Identifying products to be engineered

◦Assigning work packages

◦Making cost estimates

◦Assessing risks and opportunities

•Organizing IPTs and facilitating teamwork

•Orchestrating technical reviews

•Defining and structuring specifications, including interfaces

•Creating system structure (level-by-level development and product realization)

•Identifying and developing enabling products

Each IPT is responsible for:

•Planning their work

•Making cost estimates related to their work and the product

•Doing the work described in the team's approved work package

•Identifying and managing the risks and opportunities associated with the development of the product, including interfaces with other products in the model

A system model can be used to assist in ________________. Orchestrating incremental reviews Structuring IPT team assignmentsDeveloping specifications

"It is a product-oriented family tree composed of hardware, software, services, data and facilities." and "It is used to consistently link program and contracting reporting activities.". WBS

"Realization of system model end products should be accomplished from the bottom up so as to find and correct problems at the lowest possible level.".

The Requirements Analysis Technical Process has been completed on a portion of the XYZ system. However, an In-Progress Review (IPR) of the work products indicated that many Technical Requirements were not adequately considered in

development of the functional architecture. Consequently, a decision was made to redo Requirements Analysis using these additional missing Technical Requirements. This is an example of _____. Process Recursion

The Architecture Design Technical Process has nearly been completed on the XYZ system. As a result, Derived Technical Requirements were baselined that pertain to one of the XYZ proposed subsystems, Subsystem ABC. These have resulted in the initiation of the Stakeholder Requirements Definition Process for Subsystem ABC. Meanwhile, Technical Process

activities continue at the XYZ system level. This is an example of _____. Process Recursion

Efforts are focused on continued trade studies working toward a final System Specification and demonstration of design

maturity during the _____ phase. Technology Maturation and Risk Reduction

Which phase has outputs that include validation of the manufacturing processes and confirmation that End Products are

being manufactured in accordance with the specified manufacturing processes? Production and Deployment

System: An aggregation of End Products and Enabling Products that achieves a given purpose

Products: A 'system' consists of a wide variety and large number of different products.

Categories of such products include:

•End Products, which actually perform the intended operational functions of the system

•Enabling Products, which are those products that must be available to enable the End Product to be developed and supported over its life cycle

Realization: For each end product design solution, provides a product in a form suitable for meeting the applicable acquisition life cycle phase exit criteria, including verification and validation and transitioning the product to the parent system model for integration into another end product or to the customer.

Role of Systems Models: In order to unambiguously describe various Systems Engineering processes and activities as well as provide a framework for their application, a system model is used.

Work Breakdown Structure (WBS): Is a product-oriented family tree composed of hardware, software, services, data and facilities. MIL-STD-881 provides details on use of a WBS to include illustrative WBSs for a variety of defense system categories. Within the DoD, a WBS is the most common way that a system model is formally documented

Iteration and Recursion: Are key concepts in the application of Systems Engineering processes

•Iteration: The re-application of processes already applied to a system model based on feedback indicating a problem that needs resolution

•Recursion: The repeated application of the same Technical Processes to either successively lower system models within the system structure or to end products at successively higher levels

Systems Model - Systems Engineering Connection: Is a structure based on a hierarchy of layered systems models which provides the basis for Top-Down System Design and Bottom-Up Product Realization

•Top-Down System Design: System Design Processes are applied to each 'system model' of the system structure. Upper system models must be fully defined and appropriate Technical Reviews successfully completed in order to be able to start development of a lower system model. This application of System Design Processes continues until all system model end products can be built (or coded), bought, or reused/off-the-shelf and are ready for realization.

•Bottom-Up Product Realization: At the point when end products are ready for realization, Product Realization Processes are applied from the bottom up to realize the design solution for that end product. An end product obtained from the

Implementation Process is then verified, validated and transitioned for assembly and integration into its parent system model end product which in turn is verified, validated and transitioned. This sequence continues until the desired system-level End Product is realized.

Specifications: A key part of Systems Engineering involves the development and management of various specifications. The system model aids in understanding which products and their interfaces need to have specifications as outputs of the System Design Processes.

MIL-STD 961, Defense and Program-Unique Specification Format and Content, is the DoD specification standard. It defines generic categories of specifications as: System Specification, Performance Specification, Detail Specification, Item Specification and Software Specification.

Defense Acquisition Life Cycle: The 5000-series of DoD publications specifies policies and processes to be applied within the context of the acquisition life cycle. Phase entry and exit criteria are used for determining the maturity of the system under development and whether it is ready to proceed (or transition) to the next acquisition phase.

Summary of key Systems Engineering activities by defense acquisition phase include:

•Materiel Solution Analysis Phase: Is focused on trade studies and concept analyses to better understand Stakeholder Requirements.

•Technology Maturation & Risk Reduction (TMRR) Phase: Continued trade studies and analyses working toward a final System Specification, risk analysis of key and enabling technologies, and evidence of design maturity via a PDR.

•Engineering and Manufacturing Development Phase: Completion of any remaining preliminary design efforts and start of critical design activities, which culminate in an initial Product Baseline. End Products are implemented, integrated and verified to that baseline.

•Production and Deployment Phase: Low-Rate Initial Production (LRIP) units are constructed using the processes and tools planned for final production. LRIP units are also used for initial product validation. Activities also include ramp-up to full-rate production and delivery to the first receiving organizations.

•Operations and Support Phase: Includes monitoring of service use data to determine and correct any problems with the End Products being used. Support of disposal or retirement activities may also be needed.

1.6

A SEP is prepared by the Program Management Office and is one of the expected outcomes of the Technical Planning Process.

Contracting considerations include:

•Formally evaluating Systems Engineering during the source selection process

•Assessing a contractor's Systems Engineering past performance and demonstrated process maturity level as part of source selection considerations

•Using various contract types (e.g., incentive or award fees) to promote Robust Systems Engineering

The Systems Engineering Plan is first required at program initiation at Milestone B. False

"Rules for Robust Flying" found posted anonymously in a aircraft squadron ready room:

Regarding flying near the edges of the flight envelope:

1.Try to stay in the middle of the air.

2.Do not go near the edges of it.

3.The edges of the air can be recognized by the appearance of ground, buildings, sea, trees and interstellar space. It is much more difficult to fly there.

A robust (or resilient) design is a flexible and adaptable one that is tolerant of end product failure points and/or operating conditions and accommodates human interaction with the system. In robust design, errant excursions outside the operating 'flight envelope' of an end product do not necessarily result in catastrophic consequences.

Use of Open System Architectures---key to flexible and adaptable designs---is another characteristic of robust Systems Engineering.

An Open System Architecture (OSA) is appropriate for some module interfaces and is emphasized by DoD policies. An OSA uses commercial or non-proprietary (i.e., open system) standards Standards

The DoDAF is used to formally document a program's architectures via a series of highly-formatted 'viewpoints'. One of these is the Standards Viewpoint (StdV). The StdV articulates applicable operational, business, technical and industry policies, standards, guidance, constraints, and forecasts that will be employed on a given program.

An extensive collection of DoD endorsed IT-related standards (many of them are commercially-based open standards) has been created for programs to consider using. Those that are appropriate are incorporated into that program's technical architecture. This collection of standards is documented in the GIG Technical Guidance Federation.

More information about the DoDAF and the GIG Technical Guidance Federation is available in References. for selected Key Interfaces. Potentially, this allows multiple vendors to implement different modules which may be totally different internally, but which externally function equivalently in their parent system End Product.

The DoD characterizes an Open System as one which:

•Is based around a modular design, and

•Uses widely supported and consensus-based ('open') standards for its key interfaces, and

•Successfully verifies and validates the openness of these interfaces

Other advantages of Open System designs are that they:

•Better adapt to evolving requirements and threats

•Promote easier technology transition

•Facilitate system integration efforts

•Contribute to a 'robust' design

•Reduce development time and life cycle costs

•Enhance interoperability, reuse and supportability

•Provide better access to cutting-edge technologies

•Mitigate technology obsolescence and single-supplier risks

Which of the following statements about Robust Systems Engineering and Open Systems are correct?

Key aspects of Robust Systems Engineering include robust design and use of Open System Architectures.", "Enablers for effective use of Open System Architectures are a modular design and the identification of Key Interfaces." and "The Requirements Analysis Process and the Architecture Design Process play important roles in modular design.".

A model is a "physical", mathematical or logical representation of an system entity, phenomenon, process or end product. A simulation is the manipulation of that model. Modeling and Simulation (M&S), properly used, can be highly effective Systems Engineering tools applicable across the total life cycle. It is not uncommon for hundreds of different M&S assets to be used on a major program.

Some examples of M&S usage include:

•Using M&S to explore concept alternatives, reliability, availability, maintainability, transportability, human-machine interfaces and estimate life cycle sustainment costs

•Using modeling environments provided by Systems Engineering tools, Computer-Aided Design (CAD), etc. to better manage complexity, increase design quality and improve productivity

•Helping to answer questions about the probability of meeting requirements for system performance

•Selective use as part of the verification and possibly, the validation processes

•During production, using M&S to make the manufacturing process more efficient

•Predicting maintenance and repair levels anticipated during system operation

Which of the following is characteristic of Open Systems Architectures (OSAs)? They facilitate technology and software upgrades over a system's life.

'Ethics' is related to morality, but the two terms are not synonymous.

•Ethics: The rules or standards governing the conduct of a person or the conduct of the members of a profession

•Morality: Concern with the distinction between good and evil or right and wrong; right or good conduct

Executive Order 12731

Avoiding financial conflicts impacting duty performance

•Not using information for private financial gain

•Prohibition on solicitation for financial gain

•Not using public office for financial gain

•Avoiding inappropriate outside employment

•Good faith discharge of financial obligations

•Adhering to equal opportunity laws

•Disclosing waste, fraud, abuse and corruption to appropriate authorities

•Avoiding the appearance of non-ethical behavior

Essential considerations that affect the conduct of Systems Engineering within a DoD program include:

•Systems Engineering Plan (SEP): A detailed formulation of actions that should guide all technical aspects of an acquisition program. It is established early in the program and updated at each subsequent milestone and as needed. It is a living document, tailored to the program, and a government technical roadmap that supports program management.

•Robust Systems Engineering: Refers to the use of a disciplined Systems Engineering approach in conjunction with a robust (or resilent) product design. A "robust design" is one that:

◦Encompasses design and process flexibility which can rapidly, safely and affordably accommodate change

◦Is tolerant of end product failure points and/or operating conditions

◦Employs modular architectures with open systems standards used for selected Key Interfaces

•A Model is a 'physical,' mathematical or logical representation of an system entity, phenomenon, process or end product. A Simulation is the manipulation of that model. Modeling and Simulation (M&S) can be an effective Systems Engineering tool across the life cycle.

Open Systems Architectures: Use technical interface standards based on non-proprietary, "open" standards that are widely used, consensus-based, published and maintained by recognized industry standards organizations.

•Evolutionary Acquisition: A type of acquisition approach used at the system level that builds and fields core portions of a system by selectively evolving it through phased upgrades. It is the preferred DoD strategy for software-intensive system developments, especially for network-centric or information-based systems. It should also be used for other types of systems whenever appropriate. The flexibility inherent in Open System Architectures facilitates effective use of Evolutionary Acquisition.

•Ethics: Ethical behavior and conduct is required for all DoD employees. Presidential Executive Order 12731 established the framework for ethical conduct of all government employees. The U.S. Office of Government Ethics (OGE) contains references on specific laws and regulations related to ethical behavior.