1. 1-1

5. Project Tasks for Mid Term Exam
Provide items listed below in briefing chart format.
1. Project introduction/background/orientation chart. (4 pts)
2. Identification of key requirements. (6 pts)
3. Program performance measures (technical, cost, and schedule) with thresholds and objectives. (5 pts)
4. Project work breakdown structure (WBS). (6 pts)
5. Integrated master plan for the WBS element(s) of interest. (6 pts)
6. Integrated master schedule in network form with personnel needs identified. (6 pts)
7. Project risk assessment. (6 pts)
8. Risk abatement plan for highest risk item/driver. (6 pts)
9. Development progress metrics. (5 pts)

6. Notes On In class Exams
A hand calculator will be useful for in class exams.
In class exams are open book and open note.
Exam questions will come from required texts and lecture material. Familiarity with the contents will save you considerable time.

7. Low Readiness in Operational Use
Historically Many Large DoD Systems Have Experienced Significant Problems That Can be Traced to Development
Low Readiness in Operational Use
Excessive Support Costs
Cost and Schedule Overruns in Development and Production
Interoperability Problem

8. Overall Purpose of Systems Engineering...
… Is to Prevent Such Problems by Providing for the:
Planning of All Technical Program Tasks
Establishing a System Configuration and Size Capable of Meeting All Schedule, Cost and Performance Constraints and Objectives
Identifying and Balancing Technical Program Risks
Monitoring and Controlling Technical Development
Defining of All Requirements for System Development, Test, Production, Operation, and Support in a Systematic and Timely Manner
Verifying System Capabilities

9. Integrates And Balances
System Engineering
Integrates And Balances
Engineering
Production
Support
Systems
Engineering
Req. Analysis
System Concept Dev.
Trade Studies
Risk Analysis • F l i g h t C o n r s Q u a l i t y A s r n c e T e s t
& E v a l u i o n S u p o r t E q i p. T e c h. M a n u l s F i e l d S u p o r t T o l D e s i g n F a b r i c t o n P r o p u l s i n S t r u c e s P u r c h a s i n g
•••
•••
••• A s e m b l y T r a i n g A v o n i c s T o l i n g
Breadth
Depth

10. How To Help Engineers Think Like Systems Engineers
CONDUCT OUR DESIGN REVIEWS AS FOLLOWS:
1. Requirements
What Are Your Requirements?
Objectives
Thresholds
Constraints
What Are Your Assumptions and Criteria
Where Did They Come From?
Customer
Specs
Derived
Strategy
Flow From Above/Allocated
Validated?
What Do They Affect?
System/Subsystem Impact
Impact on Next Level (Quantified Allocations)
How Did You Balance Your Requirements Approach & Why?
Sensitivities

11. How To Help Engineers (continued)
2. Design
What’s Your Design That Meets Requirements?
Physical Description
How Does It Work?
Functional Description
How Well Does It Meet Requirements?
Predicted Status vs. Thresholds/Objectives
Performance Substantiation
Analysis vs. Test Data
Test Data vs. Assumptions
Where’s the Data That Shows It’s the Best Design to Meet Requirements ?
Performance vs. Design Changes
Trade Studies
Where’s Your Documentation?

12. How To Help Engineers (continued)
3. Risks
What Are Your Design Challenges?
Technology
Concept
Risk vs. Benefit or Opportunity
What Are the Things That Can Keep Your Design From Meeting Requirements?
Risks
Uncertainties
What Do You Plan to Do About It?
Risk Reduction Plan
What’s Your Plan if It Can’t Meet Requirements?
Fall Back
Impact on Design/Requirements

13. DoD Acquisition Environment
Discuss McNamara Era
DoD Acquisition Environment

14. Pre-1961 Situation Analyzed
Twelve major systems were studied (ATLAS, JUPITER, POLARIS, BOMARC I, NIKE AJAX, NIKE HERCULES, 8-58, F-105, F4-H, T ALOS, NIKE-ZUES, AND SPARROW III).
Conclusions with regard to the development of these programs were:
“On the average, quality outcomes in our sample tended to exceed original predictions.
This performance was achieved, however, at the expense of:
Development time - Actual development time averaged 36% greater than predictions,
Costs - An average increase of over 200% and as much as seven times original estimates.”

15. What Did SEC DEF Do About This Situation?
Made costs equal in importance to performance and lead-time in the normal program, as a matter of policy.
Made elimination of “gold plating” a policy goal.
Made an increase in competition a policy goal.
Made reduction in cost-type contracts, particularly Cost Plus Fixed Fee, a policy goal.
Established a concept formulation and contract definition procedure.
Established a broad range of system analysis studies to aid the decision making process so that life cycle costing and long range force structure planning became an intimate and significant feature.

16. DoD Acquisition Process Changes Impacting Systems Engineering
1970 DoD Acquisition Guidelines Published
1974 MIL-STD-499A Establishes Standards for Engineering Management
1981 Pre-Planned Product Improvement (P3I) Incorporated
1985 Willoughby Templates Published
1988 Total Quality Management and Concurrent Engineering Introduced
1989 Air Force Systems Center Instituted an Integrated Product Development (IPT) Approach
1991 New DoD 5000 Series Acquisition Guidelines Signed-Off
1993 Draft of MIL-STD-499B on Systems Engineering
1994 Aeronautical Systems Center Announces Integrated Risk Management to Be Used on Proposals
1994 Process Action Team Recommends Defense Contractors Cease Using Military Specifications and Standards
New DoD 5000 Series Signed-Off
DoD 5000 Series Cancelled (presently used for interim guidance)

17. DoD 5000 Series Guidance http://www.dau.mil/ DoD 5000 Resource Center
Documents & Changes

18. Present Names for Acquisition Phases
Concept & Technology Development
System Development & Demonstration
Production & Deployment
Operation & Support

19. Program Objectives and Thresholds
Beginning at the inception of a new acquisition program, the PM shall propose objectives and thresholds for cost, schedule, and performance, that will result in systems that are affordable, timely, operationally effective, operationally suitable, and survivable. The PM shall refine these objectives and thresholds as the program matures, consistent with operational requirements.

20. Program Goals shall be Identified as Objectives and Thresholds
Every acquisition program shall establish program goals – thresholds and objectives for the minimum number of cost, schedule, and performance parameters that describe the program over its life cycle.

21. Definition – Objective*
The objective value is the value desired by the user, and the value the Program Manager tries to obtain. The objective value represents an incremental, operationally meaningful, time-critical, and cost-effective improvement to the threshold value of each program parameter.
* Reference – DoD R, Chapter 1

22. Definition – Threshold*
For performance, threshold shall mean the minimum acceptable value that, in the user’s judgment, is necessary to satisfy the need. For schedule and cost, threshold shall mean the maximum allowable value. If performance threshold values are not achieved, program performance may be seriously degraded, and the utility of the system may become questionable. If schedule threshold values are not achieved, the program may no longer be timely. If cost threshold values are not achieved, the program may be too costly, and the affordability of the system may become questionable.
* Reference – DoD R, Chapter 1

23. Policy on Cost-Performance Trade-Offs*
Cost, schedule, and performance may be traded-off within the “trade space” between the objective and the threshold without obtaining Milestone Decision Authority approval. Trade-offs outside the trade space shall require approval of both the Milestone Decision Authority and the Operational Requirements Document approval authority. Validated key performance parameters (KPPs) may not be traded-off without Requirements Authority approval.
* Reference – DoD R, Chapter 1

24. See Design Considerations in Chapter 5 of DoD 5000.2-R

25. Systems Engineering Process Engine
Process Input
Requirements
Analysis
Systems Analysis
and Control
Functional
Analysis/Allocation
Design Synthesis
and Verification
Process Output

26. Systems Engineering Process Inputs & Outputs
Life- Cycle Needs
Product Objectives & Thresholds
Cost & Schedule Constraints
Best Practices & Standards
Requirements
Control
Outputs
Balanced System Solution
Decision Support Data
Product Specifications
Product Architectures
Allocation
Design

27. Systems Engineering Requirements Analysis Activities
Process Input
Requirements
Analysis
Systems Analysis
and Control
Establish/refine operational and design requirements
Develop and refine system level functional and performance requirements and external interfaces
Provide traceability between user and design requirements
Functional
Analysis/Allocation
Design Synthesis
and Verification
Process Output

28. Functional Analysis/Allocation Activities
Systems Engineering
Functional Analysis/Allocation Activities
Process Input
Requirements
Analysis
Systems Analysis
and Control
Functional
Analysis/Allocation
Define lower level functional and performance requirements
Establish traceability of requirements to higher/lower levels
Provide design and verification criteria to support integrated system design
Design Synthesis
and Verification
Process Output

29. Systems Analysis and Control Activities
Systems Engineering
Systems Analysis and Control Activities
Process Input
Requirements
Analysis
Systems Analysis
and Control
- Evaluate and select
alternatives
- Document design solutions
- Implement risk management
process
- Maintain data and configuration
management
- Manage external and internal
interfaces
- Measure progress and structure
reviews
Functional
Analysis/Allocation
Design Synthesis
and Verification
Process Output

30. Key Systems Engineering Activities Include
1. Requirements Analysis - Throughout the acquisition process the
program office shall work with the user to establish and refine
operational and design requirements that result in the proper balance between performance and cost within affordability constraints. Requirements analysis shall be conducted iteratively with functional
analysis/allocation to develop and refine customer objectives and requirements, define performance objectives and requirements, and provide traceability among user requirements and design requirements.

31. Key Systems Engineering Activities Include
(Cont.)
2. Functional Analysis/Allocation - Functional analysis/allocation shall be performed iteratively to define successively lower level functional and performance requirements, including functional interfaces and architecture. Functional and performance requirements shall be traceable
to higher level requirements. System requirements shall be allocated and defined in sufficient detail to provide design and verification criteria to support the integrated system design.

32. Requirements Characteristics
Unambiguous- Every Requirement Has Only One Interpretation
Complete Includes All Significant Requirements, Functions,
Behaviors, Performance, Constraints, and
Interfaces
Verifiable - Cost-Effective Means Exist for People or Machines
to Check Product Against Requirements
Consistent - Requirements Not In Conflict
Modifiable - Requirements Are Easy to Change Completely and
Consistently
Correct - No Error Exists That Will Affect Design
Traceable - Origin of Requirement Is Clear
Design Free - Design Is Left to the Designer

33. Words that Don’t Provide Measurable Requirements Criteria
Fast
Should
May
Extremely
Under Most Conditions
As Appropriate
User Friendly
Should Fail Gracefully
Notes:
Requirements are problem statements.
A requirement has three parts – function, performance level, and verification means

34. Sample Weapons System Requirements Database (common data)
Number
Type
Statement
Owner
Development,
Manufacturing,
Verification,
Deployment,
Operations,
Support,
Training,
or Disposal
Text statement
IPT
(or name)

35. Sample Weapons System Requirements Database (common data Cont. 1)
WBS Parent Req. Child Req.
Element Number Number
Identifier

36. Sample Weapons System Requirements Database (common data Cont. 2)
Associated
Trade Studies
Related TPMs
TPM Names
Notes
Trade Study
Identifier
Text

37. Sample Weapons System Requirements Database (unique data by WBS)
Development: Cost, Schedule (Hardware, Software,
Facilities, Data, Materials)
Manufacturing: Primary Technology, Alternate Technology
(Availability, Cost, Risk)
Verification: Method, Description, Date
Operations: Performance Threshold, Performance Objective,
Weight, Space, Power, Cooling
Support: MTBF, Inspection Cycle, Spares Investment $,
Support Equipment Req.
Training: …
Disposal: ...

38. Sample Weapons System Requirements Database (unique data by WBS Cont
Software:
- Performance (bits processed, speed, response time)
- Constraints (standards, data format, language)
- Interfaces (software, hardware, people)
- Reliability (freq. of failure, severity of failure,
recovery of failure)
- Supportability (diagnostics, portability)

39. Key Engineering Activities Include (Cont.)
3. Design Synthesis and Verification - Design synthesis and verification activities shall translate functional and performance requirements into design solutions to include: alternative people, product and process concepts and solutions, and internal and external interfaces. These
design solutions shall be in sufficient detail to enable verification that requirements have been met. The verification of the design shall include a cost-effective combination of design analysis, design modeling and simulation, and demonstration and testing. The verification process shall
address the design tools, products and processes.

40. Key Systems Engineering Activities Include (Cont.)
4. Systems analysis and Control - System analysis and control activities shall be established to serve as a basis for evaluating and selecting alternatives, measuring progress, and documenting design decisions. This shall include:
a. The conduct of trade-off studies among requirements (operational, functional and performance), design alternatives and their related manufacturing, testing and support processes, program schedule and life-cycle cost at the appropriate level of detail to support decision making and lead to a proper balance between performance and cost.

41. Key Systems Engineering Activities Include (Cont.)
b. The establishment of a risk management process to be applied throughout the design process. The risk management effort shall address the identification and evaluation of potential sources of technical risks based on the technology being used and its application, risk mitigation efforts, and risk assessment and analysis. Technology transition criteria
shall be established as part of the overall risk management effort.

42. Key Systems Engineering Activities Include (Cont.)
c. A configuration management process to control the system products, processes and related documentation. The configuration management effort includes identifying, documenting, and verifying the functional and physical characteristics of an item, recording the configuration of an item, and controlling changes to an item and its documentation. It shall provide a complete audit trail of decisions and design modifications.

43. Key Systems Engineering Activities Include (Cont.)
d. An integrated data management system to capture and control technical data and technical manuals, provide data correlation and traceability among requirements, designs, decisions, rationale, and other related program planning, status and reporting such as work breakdown
structure, support configuration procedures, and serve as a ready reference for the systems engineering effort. Program managers shall use standard data definitions whenever possible.

44. Key Systems Engineering Activities Include (Cont.)
e. The establishment of performance metrics to provide measures of how well the technical development and design are evolving relative to what was planned and relative to meeting system requirements in terms of performance, risk mitigation, and cost.

45. See System Life Cycle with Reviews on Page 101 of Systems Engineering Fundamentals

46. The “V” Model: Decomposition & Integration
Requirements Functional Design Integration Acceptance Produce
analysis allocation and verification and deploy
ASR SRR SFR PDR CDR FCA SVR PCA
System
requirements
Fully Integrated System Hardware, Software, Ops Procedures
System
verification
Subsystem
requirements:
HWCIs
CSCIs
Subsystem
integration and
verification
Integrated HWCIs, CSCIs
Configuration
Item
Requirements
CI Integration
and verification
Each CI
Each Component,
assembly, procedure
HW assembly and
CSC integration
and verification
Ops and Support
Hardware Assemblies
Software Components
Hardware
parts and processes
Computer Software
Units
Each unit
Unit integration
and verification

47. Definitions from Systems Engineering Fundamentals
System Engineering
An interdisciplinary engineering management process that evolves and verifies an integrated, life-cycle balanced set of system solutions that satisfy customer needs.
Systems Engineering Process
A top-down comprehensive, iterative and recursive problem solving process, applied sequentially through all stages of development, that is used to:
a. Transforms needs and requirements into a set of system product and process descriptions (adding value and more detail with each level of development).
b. Generates information for decision makers, and
c. Provides input for the next level of developments.

48. The Work Breakdown Structure is a Product of the Systems Engineering Process
The program work breakdown structure (WBS) establishes the essential
framework for program and technical planning, cost estimating, resource
allocations, performance measurements, and status reporting. The WBS
shall define the total system to be developed or produced, display the total
system as a product-oriented family tree composed of hardware, software,
services, and data, and relate the elements of work to each other and to the
end product.

49. WBS Definitions
Program WBS - A program WBS shall be developed to define initially the
top three levels of a WBS for the entire acquisition cycle of the system
being acquired. A final program WBS shall be prepared by compiling the
elements of the contract WBSs with the initial program WBS.
Contract WBS - From the initial program WBS, preliminary contract
WBSs for individual contracts shall be developed to be negotiated with
the contractors involved. The contract WBS shall be extended to lower
levels by the contractor using as guidance MIL-HDBK-881.

51. Specifications shall Conform to the WBS
1. WBS elements may contain both nonrecurring and recurring effort.
2. Integrated logistics support and software shall be accommodated in the
appropriate levels of the WBS in accordance with MIL-HDBK-881.
3. Functional cost elements such as engineering, tooling, quality control, and
manufacturing are not WBS elements and shall not be represented as
such in the WBS.

52. Sample WBS Prime Items (without enablers)
Legend
SS Subsystem
PROC Process
HW Hardware
SW Software
FW Firmware
System
SS-1
SS-2
SS-3
SS-11 HW
SS-12
PROC
SS-13 HW
SS-31 HW
SS-32 SW
SS-21
SS-22
SS-221 HW
SS-222 FW
SS-121 HW
SS-122 HW
SS-211 HW
SS-212 FW
SS-213 SW
SS-2221 HW
SS-2222 SW
SS-2121 HW
SS-2122 SW

53. EXERCISE #1
Background: You have recently been assigned to the IPD Team for the Peace Whey program. Peace Whey is a recently approved FMS program which will provide 20 F-16Cs to the Kurdish Air Force (KAF). The specifications for the Kurdish F-16s call for them to be equipped with the Airborne Jamming System (AJS), an electronic warfare system. Your position will be as AJS team leader responsible for the oversight of design and testing of the AJS system, for its integration into the Peace Whey aircraft, and for the AJS lab and flight testing verification. In addition, you must act as the interface between the AJS team and the other teams making up the IPD Team for the Peace Whey program, making certain that the program office is supported in its overall coordination and management tasks.
Exercise: Referring to the Statement of Customer Requirements for AJS (Part 1) which you have been provided, develop a Work Breakdown Structure (WBS) for the AJS development and production task as a part of the overall air vehicle development task.

54. AJS Statement of Customer Requirements
Customer: Kurdish Fighter Program (Peace Whey)
Operational Need: Fighter aircraft operating in a hostile environment require extensive electronic countermeasures (ECM) to defeat air-launched and ground-launched threats to the survivability of the aircraft. These ECM systems must be capable of generating and broadcasting radio frequency (RF) energy at sufficient power levels and in appropriate patterns to defeat any threat encountered by the aircraft.

55. AJS Statement of Customer Requirements (Cont.)
Description: The AJS shall be capable of installation on a lightweight, high-speed, multi-role fighter and shall be supportable in primitive forward operating bases. The system shall be capable of transmitting radio frequency signal in the microwave frequency range at sufficient power levels and in patterns capable of successfully jamming all identified threats at the required operational range. The AJS system shall consist of the following major components:
1. Core Avionics: Shall consist of the jammer, the radar warning receiver, and the OFP software. Shall be capable of generating the required RF signal in the microwave band at required power levels and of detecting radar emissions from the threat set at the required ranges.
2. RF Switch H/I/J Band: Shall control selection of broadcast frequency bands as required.
3. Fire Control Radar Notch Filter: Shall prevent interference of the Fire Control Radar (FCR) by the AJS system.
4. Forward Transmit Antenna
5. Aft Transmit Antenna and Raydome
6. WRD-650D24 Waveguide
7. Coaxial Cable

56. AJS Statement of Customer Requirements (Cont.)
Schedule:
1. Flight Test: The Safety of Flight(SOF) unit for flight test shall be available for installation 26 months after program go-ahead.
2. First Production Delivery: The first production assembly shall be delivered 36 months after program go-ahead.
3. Delivery Rate: Delivery of AJS units shall be at the rate of 2 units per month.
4. Total Quantity: The total quantity of AJS units shall be 20.
Customer Priorities:
1. Power Transmitted.
2. Weight
3. First production delivery.
4. Cost not to exceed $125,000/unit (for 20 units).

57. See MIL-HDBK-881

58. Cost, Schedule, and Performance Risk Management
The program manager shall establish a risk management program for each
acquisition program to identify and control performance, cost, and schedule
risks. The risk management program shall identify and track risk drivers,
define risk abatement plans, and provide for continuous risk assessment
throughout each acquisition phase to determine how risks have changed.
Risk reduction measures shall be included in cost-performance tradeoffs,
where applicable. The risk management program shall plan for back-ups
in high risk areas and identify design requirements where performance
increase is small relative to cost, schedule, and performance risk.

59. Cost as an Independent Variable (CAIV)
The acquisition strategy shall address methodologies to acquire and
operate affordable DoD Systems by setting aggressive but achievable cost
objectives and managing achievement of these objectives. Cost objectives
shall be set to balance mission needs with projected out-year resources,
taking into account anticipated process improvements in both DoD and
defense industries. This concept has become known as “cost as an
independent variable,” meaning that cost shall be more of an input, and
less of an output, in the process of acquiring DoD systems.

60. Cost/Performance Tradeoffs
Life-cycle cost-performance tradeoffs shall be considered in each phase
by a life-cycle cost-performance integrated product team (CPIPT). The
organization and activities of the CPIPT is based on the principle that the
best time to reduce life-cycle cost is early in the acquisition process and
that cost performance tradeoffs analyses shall be conducted before an
acquisition approach is finalized.

64. SEMS Interrelationships