Systems Engineering Management: MSE607B Chapter 6 Part I of II System Engineering Program Planning

You might also like

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 41

Engineering Systems Engineering

Management
Management

MSE607B
Chapter 6 Part I of II
System Engineering Program Planning
Learning Objectives
 Introduce system engineering program planning
• First step in system management
 Material presented in this module leads into the
discussion of:
• The organization for system engineering in module 7
• System engineering program evaluation in module 8

2
System Engineering Process

 An iterative problem solving process based on the


fundamental cycle of analyse-synthesise-evaluate
 Provides a comprehensive process for transforming a
simple statement of user need into a complex fielded
system
 Provides the information by which the process can be
managed and improved

3
Management of System Engineering

System engineering is applicable in all phases of life cycle


Greatest benefits are derived from emphasis in early stages

4
Management of System Engineering
 Objective is to influence the design in the early phases of
acquisition, effectively and efficiently
 Leads to the identification of the individual design disciplinary
needs proceeding from system level to subsystem levels
 Goal is to ensure that requirements are properly balanced and
integrated
 Applicable engineering disciplines responsible for the design of
the individual system elements to be properly integrated
 System engineering first establishes the requirements then
ensure proper integration throughout the life cycle
 System engineering is applicable in all phases of life cycle
 Greatest benefits are derived from emphasis in early stages

5
Integration of Disciplines

6
Management and Technology Applied
to the System Engineering Process

7
System Engineering Program
Requirements
 First step in the planning process
 Involves definition of program, or project,
requirements
 Every program is different
• It is essential that system engineering requirements be
tailored accordingly
 Concepts and methods described throughout this
module are applicable to all programs
• Only the nature and depth of application may vary

8
System Engineering Planning

9
The Need for Early System Planning

 System engineering is continuous


• Commencing with the definition of a need and extending
• Through the development of the System Engineering
Management Plan (SEMP)
 As system-level requirements are defined, the planning
process leads to the identification of activities to be
accomplished to fulfill those requirements
 Design and management decisions at this stage in the
system life cycle have great impact on program
activities later on
 Need a complete and well-integrated planning effort
• Implemented from the beginning

10
Determination of Program
Requirements
 Program Requirements
• Refer to the management approach and steps to be
followed in the procurement and/or acquisition of the
system in response to a stated need
• Identification of the resources required
 Program structure should be established that
will enable cost effective:
• Design and development
• Production and/or construction
• Delivery of the system to the consumer

11
Determination of Program
Requirements (cont.)
 Includes identification of :
• Program functions and detailed tasks
• Development of an organizational structure
• Development of a work breakdown structure (WBS)
• Preparation of program schedules and cost
projections
• Implementation of program evaluation and control
capability
 Program plan provides the necessary day-to-day
management guidance

12
System Engineering Management
Plan (SEMP)
 Developed based on the Program Management Plan (PMP)
 Covers all management functions associated with system
engineering activities
 Constitutes chief engineer’s plan for identifying and
integrating all engineering activities.
 Preparation is the responsibility of the “system manager”
 May be accomplished by the customer or by a major
contractor

13
System Engineering Management
Plan (SEMP) (cont.)
 Must be developed directly from the top-level Program
Management Plan (PMP).
 Responsibility must be clearly defined and supported by
the program manager.
 Must be the key top-level design engineering plan
 Content tailored to the system requirements, program size
and complexity, and nature of the procurement and
acquisition process

14
Statement of Work (SOW)

 A narrative description of the work required for a given


project
 General guidelines:
• Short and to the point
• Written in a clear and precise manner
• Avoid ambiguity and the possibility of misinterpretation
• Describe requirements in sufficient detail
• Consider practical application and possible legal interpretations
• Avoid unnecessary repetition and incorporation of extraneous
material and requirements
• Can result in unnecessary costs
• Do not repeat detailed specifications and requirements already
covered in referenced documentation

15
Definition of System Engineering
Functions
 Cover a broad spectrum of activity
 Fulfillment of objectives require involvement in almost
every facet of program activity
 Overall basic goals for system engineering:
• Requirements developed through iterative requirements
analysis
• System design alternatives properly evaluated against
meaningful, quantifiable criteria

16
Definition of System Engineering
Functions (cont.)
 Overall basic goals for system engineering:
• All applicable design disciplines and specialty areas
appropriately integrated into the total engineering effort
• Overall system development effort progresses in a
logical manner
• Established configuration baselines, formal design review,
proper documentation supporting design decisions, and
necessary provisions for corrective action
• Various system elements/components are compatible
with each other
• Combined to provide an entity that will perform its required
functions

17
System Engineering Tasks

18
Definition of System Engineering
Tasks
 Critical tasks
• Perform a needs analysis and conduct feasibility studies
• Define system operational requirements, maintenance
concept, and TPMs
• Prepare the system Type “A” specification
• Prepare Test and Evaluation Master Plan
• Prepare the System Engineering Management Plan
• Accomplish functional analysis and allocation of
requirements

19
Definition of System Engineering
Tasks (cont.)
 Critical tasks
• Accomplish system synthesis, analysis, and design
integration functions on a continuing basis throughout
the overall design and development process
• Plan, coordinate, and conduct formal design reviews
meetings
• Monitor and review system test and evaluation activities
• Plan, coordinate, implement, and control design
changes
• Initiate and maintain production and supplier liaison,
and customer service activities

20
System Engineering Organization
and Interfaces

21
System Engineering Interfaces
 Interface
• A statement of the functional requirements and
constraints that exist at a common boundary between
• Two functions (functional interface)
• Two configuration items (physical interface)
 Interface definition and management is essential
• Breaking down the system into subsystems, modules and
components to reduce complexity may result in interface
complexity
 There must be a balance between the
complexity of any element and the
complexity of any associated interface

22
System Engineering Organization

 Must lead and ensure tasks are completed in an


effective, efficient, and timely manner using system-level
technical expertise and leadership
 Must work with, influence, and inspire many other groups
within the project
 Must have the respect and cooperation of the other
required functions

23
System Engineering Organization
(cont.)
 May be contained within the customer’s organization, with
various responding subgroups within the contractor’s
organization
 In a contractor’s organization basic structure may constitute:
• A functional approach
• A project/product line approach
• A matrix approach, or
• Various combinations thereof.
 Advantages and disadvantages associated with each of these
approaches
• Essential to recognize if the organization is to work effectively
 Need to consider external interactions involving subcontractors
and suppliers,

24
Partial Work Breakdown Structure
Development
01-00-00
Level 1 System XYZ

01-01-00 01-02-00 01-03-00 01-04-00


Level 2 Activity A Activity B Activity C Activity d

01-02-01 01-02-02 01-02-03 01-02-04


Level 3 Function 1 Function 2 Function 3 Function 4

Contract Work Breakdown Structure (CWBS) Contract Work Breakdown Structure (CWBS)
Preliminary System Design Phase Detail Design and Development Phase

25
Development of a Work Breakdown
Structure (WBS)
 Large projects organized and comprehended by breaking
them into smaller pieces
• A collection of defined "work packages" that may include a
number of tasks
• A $1,000,000,000 project is simply a lot of $50,000 projects
joined together
 Used to provide the framework for organizing and managing
the work

26
Development of a Work Breakdown
Structure (WBS) (cont.)
 Our brains can normally comprehend around 7-9 items
simultaneously
• WBS helps break thousands of tasks into chunks that
 Preparing and understanding a WBS is a big step towards
managing and mastering its complexity
 Used at project start for:
• Defining scope
• Organizing schedules
• Estimating costs
 Lives throughout the project in project schedule and used for
reporting costs
 May be used to identify/track work packages, organize data for
reporting, etc.

27
Sample WBS

Level 1 Level 2 Level 3

3A1100 Project Management


3A1200 System Engineering
2A1000 3A1300 Configuration Management
System/Program 3A1400 Contract Management
Management 3A1500 Data Management
3A1600 Integrated Logistics Support
3A1700 Supplier Management
2B1000 3B1100 Basic Research
Research and 3B1200 Applied Research
Development 3B1300 Technology Development
3C1100 Airframe
3C1200 Propulsion
System XYZ 3C1300 Communications
3C1400 Navigation/Guidance
2C1000 3C1500 Fire Control
Prime Mission 3C1600 Countermeasures
Equipment 3C1700 Reconnaissance Equipment
3C1800 Flight Controls
3C1900 Auxiliary Electronics
3C2000 Armament/Weapons Equipment
3C2100 Hydraulic Equipment
3D1100 Peculiar Support Equipment - Organizational Level
3D1200 Peculiar Support Equipment - Intermediate Level
2D1000 3D1300 Peculiar Support Equipment - Depot Level
Support
3D1400 Common Support Equipment - Organizational Level
Equipment
3D1500 Common Support Equipment - Intermediate Level
3D1600 Common Support Equipment - Depot Level

II - System Engineering
Specification/Documentation Tree

II - System Engineering
Specification/Documentation Tree
(cont.)

30
Specification/Documentation Tree
(cont.)

31
Specification/Documentation Tree
(cont.)
 Provides a hierarchical description of the various
specifications for a systems development as part of a
systems engineering process
 Developed from the top down, commencing with the
preparation of the system specification
• Subsequently, additional specifications are applied
 Top down development of design requirements is
critical
• Meet the system engineering objectives

32
Specification/Documentation Tree
(cont.)
 Extreme care must be exercised in the initial
identification and application of specifications and
standards
 Costly results if proper level of attention is not directed
from the beginning
• Critical task is tailoring specifications to particular system
application

33
Technical Performance Measurement
(TPM)
 Key indicator of progress, parameter or a metric that can be
used to monitor the progress or performance of selected
requirements
 Monitored to ensure that it remains within tolerances as an
indication of the progress of the design
 One of the most commonly used systems engineering tools.
 Identified at a very early stage in the systems engineering
process
• During Conceptual Design
 Progress is continually monitored throughout the Acquisition
Phase as a major risk-mitigation measure

34
Development of Program Schedules

 Individual program tasks are presented in terms of a


time line
• A beginning time and an ending time
 Developed to reflect work requirements throughout all
phases of a program
 Commences with identification of major program
milestones at the top level
 Proceeds downward through lower levels of detail

35
Development of Program Schedules
(cont.)
 A system engineering master schedule (SEMS) is
prepared:
• Laying out major program activities on basis of elapsed time
• Serves as a reference for a family of subordinate schedules
• Progress against a given schedule is measured at the bottom
level
• Task status information is related to appropriate cost account
 Techniques:
• Bar chart
• Milestone chart
• Combined milestone/bar chart

36
Program Schedule –
Sample Bar Chart

37
Program Schedule –
Sample Milestone Chart

38
Summary

 Topics
• System engineering program requirements
• System engineering management plan (SEMP)
• Determination of “outsourcing” requirements
• Integration of design specialty plans
• Interfaces with other program activities
• Management methods/tools
• Risk management plan
• Global applications/relationships

39
Homework Assignment
 Chapter 6 Part I – Textbook page 334
• Answer questions 1, 3, 9.

 Continue to read Chapter 6 - Engineering


Program Planning
• Pages 292-334

40
Questions? Comments?

41

You might also like