Lecture 2.3: The Systems Engineering Plan SEP

1
Lecture 2.3 The Systems Engineering Plan (SEP)
Dr. John MacCarthy UMBC CMSC 615 Fall, 2006
2
Agenda

• Systems Engineering Management References
• The Systems Engineering Plan (SEP)
• The DoD SEP Preparation Guide
• Your Projects SEP Development
• Recommended SEP Structure and Content
• Selected Section Elaborations
• The Voice of Experience
• Class Exercise 2.2

3
Systems Engineering Process References

• Engineering Management MIL-STD-499A, February
  1995 cancelled lthttp//www.dsp.dla.milgt
• IEEE Standard for Application and Management of
  the Systems Engineering Process IEEE-12207-2005
  lthttp//www.ieee.org/web/standards/home gt
• EIA Standard Process for Systems Engineering
  ANSI/EIA 632-1998, January, 1999
  lthttp//www.ieee.org/web/standards/homegt
• Systems Engineering System Life Cycle Processes
  ISO/IEC 15288, 2003 lthttp//www.iso.org/iso/en/I
  SOOnline.frontpagegt
• INCOSE Systems Engineering Handbook, V2A June,
  2004 lthttp//www.incose.org/ProductsPubs/products
  gt
• NASA Systems Engineering Handbook June 1995
  lthttp//ldcm.gsfc.nasa.gov/library/Systems_Enginee
  ring_Handbook.pdfgt
• Capability Maturity Model Integration (CMMI) for
  Systems Engineering and Software Engineering
  (SE/SW), Version 1.1 December 2001
  lthttp//www.sei.cmu.edu/cmmi/models/v1.1se-sw-cont
  .docgt

4
Systems Engineering Plan (SEP) orSystems
Engineering Management Plan (SEMP)

• A SEP and a SEMP are the same thing, it depends
  on the reference
• Most references indicate that development of a
  SEP (or SEMP) is an essential Systems Engineering
  Management planning activity.
• A SEP or SEMP is REQUIRED for most medium to
  large government Projects (DoD, NASA, DOE,
  Treasury, FBI, etc.)
• The SEP or SEMP is generally the first Systems
  Engineering artifact produced and one of the
  first programmatic documents to be produced.
• It is generally produced in parallel with the
  Programs Acquisition Strategy, WBS, and Cost and
  Schedule baseline
• Purpose of the SEP or SEMP
• Describe the Scope of Systems Engineering for a
  Project
• Describe how Systems Engineering will be done on
  the Project
• Guide all technical aspects of the project
• It provides a comprehensive, integrated
  technical plan that reflects the programs
  strategy to achieve its objectives within
  acceptable risks.

5
The DoD Systems Engineering Plan Preparation
Guide (SEP PG)

• Reference
• Systems Engineering Preparation Guide, (May 2006)
  lthttp//www.dau.mil/pubs/dam/05_06_2006/may-june06
  .pdfgt
• Developed by USD ATL Systems and Software
  Engineering
• SEP PG Purpose
• guides program teams in generating their
  programs Systems Engineering Plan (SEP)
  regardless of ACAT level of the program.
• Note A SEP (or SEMP) is required for all
  Programs, regardless of ACAT level

• SEP PG Outline
• 1.0 Purpose of Guide
• 2.0 General Guidelines and Submittal
  Instructions
• 3.0 Preferred Format and Specific Preparation
  Guidelines
• 4.0 Acknowledgements
• 5.0 Acronyms

This Lecture focuses on Chapter 3, the
recommended format for a SEP
Note The SEP PG is heavily hyperlinked to
Defense Acquisition Guidebook
6
SEP PG RecommendedSEP Annotated Outline

• The SEP PG provides a recommended annotated
  outline (AO) for the SEP
• It only goes down two levels
• It provides a description of what should go in
  each section
• Companies generally have (more detailed)
  recommended AOs for SEPs (or SEMPs) and/or
  example SEPs (SEMPs)
• For the purposes of this course, I have developed
  a more detailed SEP AO (based on the SEP PG) that
  I have made available on Blackboard for your use.
• The rest of this lecture uses this SEP AO to
  illustrate the SEP PG recommended SEP content

• SEP PG Outline
• Title and Coordination Pages
• Table of Contents
• 1.0 Introduction
• 1.1 Program Description and Applicable Documents
• 1.2 Program Status as of the Date of This SEP
• 1.3 Approach for SEP Updates
• 2.0 Systems Engineering Application to Life
  Cycle Phases
• 2.1 System Capabilities, Requirements, and Design
  Considerations
• 2.2 SE Organization Integration and Technical
  Authority
• 2.3 Systems Engineering Process
• 2.4 Technical Management and Control
• 2.5 Integration and other Program Management
  Control Efforts

7
Writing Your Projects SEP

• You will be writing a SEP over the next two
  months (recall it is one of the artifacts to be
  provided in the Project Notebook).
• As we address a SE topic, your homework will
  require you to update a selected portion of your
  projects SEP
• The sections of the SEP that you are required to
  write for the homework due next week is written
  in RED BOLD
• Sections that you will not be developing in this
  course are written in GRAY
• Note as a matter of style, higher level sections
  should briefing summarize the topics covered by
  the next lower level.
• Section 1 Example This section provides a
  summary description of the Program and identifies
  applicable documents (1.1), summarizes the
  Programs technical status (1.2), and describes
  the Programs approach for SEP updates (1.3).

8
SEP Structure Section 1

• 1.0 Introduction
• 1.1 Program Description Applicable Documents
• 1.1.2 Program Description
• - AV-1 Information
• 1.1.2 Applicable Documents
• - Source Programmatic Technical Documents
• - Applicable Standards
• - Program Programmatic Technical Documents
• 1.2 Program Technical Status
• 1.3 Approach for SEP Updates
• - Triggers, Approach, Change Log

9
Section Content Elaboration1.2 Program
Technical Status

• Describes (Full) Life Cycle acquisition model
  used by the program
• Provide a high-level schedule for the (Full) Life
  Cycle
• Summarize Acquisition Life Cycle Model (per DoDI
  5000.2)
• Identify the Phase you are entering
• Identify the Entry and Exit milestones for the
  Phase
• Identify describe planned increments/spirals
  (if using incremental or spiral acquisition)
• Top-level schedule should indicate multiple life
  cycles (one for each increment/spiral)
• Identify Increment/Spiral that is to be developed
  under this version of the SEP

10
SEP Structure Sections 2.1 2.2

• 2. Systems Engineering Application to Life Cycle
  Phases
• 2.1 Capabilities, Requirements and Design
  Considerations
• 2.1.1 Capabilities to be Achieved
• 2.1.2 Concept of Operations
• 2.1.3 Key Performance Parameters
• 2.1.4 Technical Requirements
• - Requirements Document Hierarchy/Spec Tree
• 2.1.5 Statutory and Regulatory Requirements
• 2.1.6 Certification Requirements
• 2.1.7 Design Considerations
• - Existing/Planned component and/or
  communications systems that
• constrain design
• - Development methodologies that impact
  design
• - Topics from DAG 4.4
• 2.2 Systems Engineering Organizational
  Integration and Technical Authority
• 2.2.1 Organizational Responsibilities
• 2.2.2 Organization of IPTs
• 2.2.3 Integration of SE into Program IPTs
• 2.2.4 Technical Staffing and Hiring Plan

11
SEP Structure Section 2.3

• 2. Systems Engineering Application to Life Cycle
  Phases
• 2.3 Systems Engineering Process
• 2.3.1 Technical Approach and Approach
  Selection
• 2.3.1.1 Technical Development Process
• - Development Model for Phase (e.g.,
  V, RUP, etc.)
• - SE Process ( how it fits into the
  development model)
• - Development Activity Descriptions
  for Phase
• 2.3.1.2 Technical Management Process
• 2.3.1.2.1 Technical Planning include WBS
• 2.3.1.2.2 Technical Assessment
• 2.3.1.2.3 Requirements Management
• 2.3.1.2.4 Data Management
• 2.3.1.2.5 Interface Management
• 2.3.2 Process Improvement
• 2.3.3 Tools and Resources Tools, Models
  Simulations, Facilities
• 2.3.4 Approach for Trades

12
Section Content Elaboration2.3.1.1 Technical
Development Process

• Subsection should include a summary of the
  Development Life Cycle for the increment/spiral
  of interest
• Development Life Cycle Model (LCM) Diagram
• Development Schedule (showing activities and key
  milestones)
• Subsections should provide a summary description
  of each activity identified in the LCM. Each
  activity description should include
• Entry Event
• Principal Artifacts to be produced (and by whom)
• Relationship between artifacts
• Decision Authority for the Activity
• Exit Event/Milestone
• Subsection should summarize how SE Process will
  be applied during the development life cycle.

• Example
• X.1 Development Process Summary
• X.2 SE Process
• X.3 System Requirements Development
• X.4 Design Requirements Development
• X.5 Design
• X.6 Coding and Unit Testing
• X.7 Integration Testing and Verification
• X.8 Deployment

13
SEP Structure Sections 2.4 2.5

• 2. Systems Engineering Application to Life Cycle
  Phases
• 2.4 Baseline Management and Control
• 2.4.1 Technical Baseline Management and
  Control
• 2.4.1 Configuration Management
• 2.4.2 Technical Baseline Development
• 2.4.3 Technical Objectives
• 2.4.4 Traceability, Verification and Validation
• 2.4.5 Cost and Schedule Considerations
• 2.4.6 Data Rights
• 2.4.2 Technical Reviews
• 2.5 Integration and Program Management Control
• 2.5.1 Acquisition Strategy
• 2.4.2 Risk Management
• 2.4.3 Integrated Master Plan and Integrated
  Management Schedule
• - High-level Activity/Milestone schedule here
• 2.4.4 Earned Value Management
• 2.5.5 Contract Management

14
Section Content Elaboration2.4.2 Technical
Reviews

• Develop a subsection for each major Milestone
  Review, at a minimum there should be subsections
  devoted to SRR, SFR, PDR, CDR, TRR, and SVR
• Each section should address the following
• The purpose of the Review
• Use of entry/exit criteria
• Known Key Entry/Exit Criteria
• Key artifacts to be approved
• The organization that will run the review, those
  that will attend, and the title of the individual
  that will have decision authority
• Reference the Subsection in 2.3.1.1 that
  indicates the review as an exit/entry milestone.
• Other Reviews that are generally included are
  PMRs, IPRs, TIMs, Stakeholder Reviews, etc.
• Low-level meetings should not be included

15
The Voice of Experience

• There is no perfect one size fits all SEP
• Generally a SEP author will have to balance
• Management desire for a short SEP
• Short timeline for development of the SEP
• Management desire for a reasonably complete SEP
• Management perception that some parts of the SEP
  are more important than others
• Result is often a SEP that does not address
  everything that it is supposed to (but one that
  does meet the needs of the project)
• Meet often with the customer and stakeholders
• Find an existing SEP that your Manager or
  Customer likes and use it as a framework
• Ask for inputs from stakeholders
• Steal what makes sense from other documents
• Edit/Integrate inputs to ensure document flows
  and tells a coherent story (and is not just a
  set of unrelated topics)

• Develop your SEP in the following manner
• Annotated Outline (AO)
• AO Review (by stakeholders customer)
• Rough Draft (RD)
• RD Review (by stakeholders customer)
• Draft
• Draft Review (by stakeholders customer)
• Final (for approval by Program Manager and
  Customer)

Who are the SEP Stakeholders?
16
Class Exercise

• Develop an Outline for Section 1.2 (Life Cycle
  Model)
• Develop an Outline for Section 2.3.1.1
  (Development Model)
• Develop an Outline for Section 2.4.2 (Technical
  Reviews)

17
Backup Slides
18
Part 1 of SEP

• 1.1 Program Description and Applicable Documents
• Top-Level System Description (AV-1)
• List of Key Program Documents
• 1.2 Program Status as of the Date of This SEP
• Program Life Cycle Model Indication of
• Previous Milestones Achieved
• Current Phase
• Key Milestones and Critical Path Events for
  current phase
• Status of
• Deliverables
• Key Programmatic Interface Events
• 1.3 Approach for SEP Updates
• Events that trigger SEP updates
• List of Previous SEP Submittals
• Change Log Table

19
Part 2 of SEP

• 2.1 System Capabilities, Requirements, and Design
  Considerations
• Capabilities to be achieved
• Concept of Operations
• Key Performance Parameters
• Certification Requirements
• Design Considerations
• 2.2 SE Organization Integration
• Organization of IPTs
• Organizational Responsibilities
• Integration of SE into Program IPTs
• Technical Staffing and Hiring Plan
• 2.3 Systems Engineering Process
• Systems Engineering Process (integrated into the
  projects Life Cycle with special emphasis on the
  current phase)
• Basis for SE Process Selection
• Planned Process Improvement Activities
• SE Size, Effort and Schedule
• Overview of Project Technical Objectives
• SE Process Inputs
• SE Deliverables ( the CLIN) Results

• 2.4 Technical Management and Control
• Technical Baseline Management and Control
  Requirements Management (CM) Process(es)
• List of Specification Documents (Spec Tree)
  Status
• Metrics that will be used to indicate technical
  progress maturity (TPMs, CTPs, MOEs, MOSs,
  etc.)
• Process for tracking technical progress
• Approach to Requirements, Validation, and
  Verification Traceability (including Tools)
• Overview of key technical data that will be
  available to the government and contractor
• Technical Review Plan (Key Reviews, Timing, entry
  and exit criteria, etc.)
• 2.5 Integration and other Program Management
  Control Efforts
• Acquisition Strategy
• Risk Management
• Integrated Master Plan
• Earned Value Management
• Contract Management