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

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

Systems Engineering Process References Engineering Management [MIL-STD-499A, February 1995] [cancelled] <http://www.dsp.dla.mil> IEEE Standard for Application and Management of the Systems Engineering Process [IEEE-12207-2005] <http://www.ieee.org/web/standards/home > EIA Standard Process for Systems Engineering [ANSI/EIA 632-1998, January, 1999] <http://www.ieee.org/web/standards/home> Systems Engineering – System Life Cycle Processes [ISO/IEC 15288, 2003] <http://www.iso.org/iso/en/ISOOnline.frontpage> INCOSE Systems Engineering Handbook, V2A [June, 2004] <http://www.incose.org/ProductsPubs/products> NASA Systems Engineering Handbook [June 1995] <http://ldcm.gsfc.nasa.gov/library/Systems_Engineering_Handbook.pdf> Capability Maturity Model Integration (CMMI) for Systems Engineering and Software Engineering (SE/SW), Version 1.1 [December 2001] <http://www.sei.cmu.edu/cmmi/models/v1.1se-sw-cont.doc>

Systems Engineering Plan (SEP) or Systems 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 Program’s 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 program’s strategy to achieve its objectives within acceptable risks.”

The DoD “Systems Engineering Plan Preparation Guide (SEP PG)” Reference: Systems Engineering Preparation Guide, (May 2006) <http://www.dau.mil/pubs/dam/05_06_2006/may-june06.pdf> Developed by USD AT&L Systems and Software Engineering SEP PG Purpose: “guides program teams in generating their program’s 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

SEP PG Recommended SEP 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

Writing Your Project’s 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 project’s 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 Program’s technical status (1.2), and describes the Program’s approach for SEP updates (1.3).”

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

Section Content Elaboration: 1.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

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

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

Section Content Elaboration: 2.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

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

Section Content Elaboration: 2.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

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?”

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)

Backup Slides

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

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 project’s 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 SE role in the development of the Product WBS Overview of the TEMP Methods, Tools and Resources Approach to Modeling and Simulation Approach to Trade Studies and Analysis (Requirements, Design, and Life Cycle Cost) 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