Lecture 2.1b: DoD Acquisition Process (SEF Ch 2)

Slides:



Advertisements
Similar presentations
Systems Engineering From a Life Cycle Perspective John Groenenboom Director Engineering – Mesa Boeing Rotorcraft Dec 12, 2007.
Advertisements

Ninth Lecture Hour 8:30 – 9:20 pm, Thursday, September 13
TITLE OF PROJECT PROPOSAL NUMBER Principal Investigator PI’s Organization ESTCP Selection Meeting DATE.
1 Lecture 1.4: Life Cycle Models Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Chapter 2 – Software Processes
Chapter 2 – Software Processes Lecture 1 1Chapter 2 Software Processes.
1 Lecture 3.2: Technical Reviews and Audits (SEF Ch 11) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
“Common Process for Developing Briefings for Major Decision Points” INSTRUCTIONS Provide Feedback via to: Lois Harper PEO C4I and Space
Systems Engineering in a System of Systems Context
Rational Unified Process
Software Engineering General Project Management Software Requirements
1 Lecture 2.6: Organization Structures Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Trade Study Training Need and Goals Need Consistent methodologies and practices performing trade studies Pros/cons, advantages/disadvantages, customer/management.
Systems Engineering Management
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Requirements Engineering Process – 1
Chemical Biological Defense Acquisition Initiatives Forum (CBDAIF)
1 Lecture 4.3a: Metrics Overview (SEF Ch 14) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Chapter : Software Process
1 Lecture 5.3: SEF Ch 4 Requirements Analysis Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
1 Lecture 3.9: RFP, SOW and CDRL (SEF Ch 19) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Software Engineering Chapter 15 Construction Leads to Initial Operational Capability Fall 2001.
Software Development *Life-Cycle Phases* Compiled by: Dharya Dharya Daisy Daisy
Chapter 2 The process Process, Methods, and Tools
Engineering, Operations & Technology | Information TechnologyAPEX | 1 Copyright © 2009 Boeing. All rights reserved. Architecture Concept UG D- DOC UG D-
Lecture 2.3: The Systems Engineering Plan (SEP)
Software System Engineering: A tutorial
Business Systems Development SDLC and introduction to the Microsoft Solutions Framework Team and Process Models.
The Challenge of IT-Business Alignment
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
1 Lecture 5.2a: SEF Ch 8 SE Outputs Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Software Engineering Lecture # 17
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
New 5000 Documents 14 May 2001 New 5000 Documents 14 May 2001 Defense Systems Management College Acquisition Policy Department.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Life Cycle Logistics.
Verification and Validation — An OSD Perspective — Fred Myers Deputy Director, Test Infrastructure Test Resource Management Center November 4, 2009.
Chapter 8 Workflows of the Process Taken from Walker Royce’s textbook – Software Project Management plus a number of Personal Comments.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Ch7: Software Production Process. 1 Waterfall models  Invented in the late 1950s for large air defense systems, popularized in the 1970s  Main characteristics:
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
1 Lecture 2.4a: SEF SE Planning and the SEP (SEF Ch 16) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
1 Systems Engineering Initiatives 26 June 2007 Dr. Don Gelosh Sr. Systems Engineering Consultant OSD(AT&L)/SSE/ED.
1 Lecture 2.3: SE Process (SEF Ch 3) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
PRODUCTION/ DEPLOYMENT
Principal Investigator ESTCP Selection Meeting
Process 4 Hours.
DoD Template for Application of TLCSM and PBL
Sample Fit-Gap Kick-off
Supportability Design Considerations
Life Cycle Logistics.
Competitive Prototyping – the New Reality
Lecture 3 Prescriptive Process Models
DoD SE Processes (DAG section)
CS 389 – Software Engineering
LOGISTICS ACQUISITION, AN EMPHASIS ON PLANNING FOR PERFORMANCE
Principal Investigator ESTCP Selection Meeting
Milestone A to Milestone B Requirements Management Activities
Chapter 2 – Software Processes
DOD’S PHASED SYSTEM DEVELOPMENT PROCESS
Principal Investigator ESTCP Selection Meeting
Principal Investigator ESTCP Selection Meeting
Presentation transcript:

Lecture 2.1b: DoD Acquisition Process (SEF Ch 2) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006

Chapter 2: Systems Engineering Management in DoD Acquisition [1] NEW DOD 5000 Process: OLD DOD 5000.R Process Chapter 2: 2.1 Introduction 2.2 Recent Changes 2.3 Acquisition Life Cycle 2.4 SE in Acquisition 2.5 Summary Points S2-A Technology Readiness Levels S2-B Evolutionary Acquisition Considerations Notes: The current SEF Guide describes the OLD DODI 5000.2-R Acquisition Process We just discussed the NEW version (DODI 5000.2) Some Major Differences: Concept & Technology Development are separated by MS-A Name of the final Phase Changed Some new Milestones MNSs and ORDs are replaced by ICDs and CDDs Others USE THE NEW ACQUISITION WALL CHART As such, although many of the specifics of Chapter 2 are dated, the general approach described for iterative application of the SEP process to the DoD Acquisition Phases is still valid. Chapter 2 Conclusions are still valid.

Chapter 2: Systems Engineering Management in DoD Acquisition [2] Overview of OLD DoD 5000.R Concept Subphase Overview of OLD DoD 5000.R Technology Development Subphase Note: This model is no longer valid. See NEW Acquisition wall chart for NEW Concept Development and Technology Development Phases.

Chapter 2: Systems Engineering Management in DoD Acquisition [3] Overview of SE Process in OLD SDD Phase (System Requirements): Overview of SE Process in OLD SDD Phase (Design Requirements & Design): Note: Time Scale is off. See NEW Acquisition wall chart for SDD Phase.

Chapter 2: Systems Engineering Management in DoD Acquisition [4] Overview of SE Process in OLD Production and Deployment Phase: Overview of SE Process in OLD Operations & Support Phase: Note: Time Scale is off. See NEW Acquisition wall chart for Product & Deployment and Sustainment & Disposal Phases.

2.5 Summary Points The development, acquisition, and operation of military systems is governed by a multitude of public laws, formal DoD directives, instructions and manuals, numerous Service and Component regulations, and many inter-service and international agreements. The system acquisition life cycle process is a model used to guide the program manager through the process of maturing technology based systems and readying them for production and deployment to military users. The acquisition process model is intended to be flexible and to accommodate systems and technologies of varying maturities: Systems dependent on immature technologies will take longer to develop and produce, Systems that employ mature technologies can proceed through the process relatively quickly. The system engineering effort is integrated into the systems acquisition process such that the activities associated with systems engineering (development of documentation, technical reviews, configuration management, etc.) support and strengthen the acquisition process. The challenge for the engineering manager is to ensure that engineering activities are conducted at appropriate points in the process to ensure that the system has, in fact, achieved the levels of maturity expected prior to progressing into succeeding phases.

S2-A Technology Readiness Levels New DOD 5000.2 Process requires a Technology Readiness Assessment (TRA) prior to Milestone B (for Major Acquisitions) Critical Technologies need to be identified and characterized by Technology Readiness Level (TRL) Chart to right provides definition for each level. For Milestone B, most (all) critical technologies should be at TRL 5/6 or higher

S2-B Evolutionary Acquisition Considerations [1] Evolutionary Acquisition is Characterized by: Evolving Architectures Block Development & Incremental Delivery (each block provides additional or upgraded capability) Phased, concurrent development of Blocks/Increments Planning Considerations: Clear description of core system and subsystems/ components most likely to evolve Process for obtaining, evaluating and integrating operational feedback, technology advancements, & emerging commercial Products Planning for evolutionary block upgrade evaluation, requirements validation and program initiation Description of the management approach for evolutionary upgrades with in block and the constraints and controls associated with incremental delivery of capability Risk Analysis of the developmental approach, both technical and managerial

S2-B Evolutionary Acquisition Considerations [2] SE Planning Emphasis: Openness and Modularity of the design of the core system architecture (to facilitate upgrades) Structure of Baseline Documentation (upgrade flexibility) Impact of Evolutionary Acquisition on baseline development and document control Structure of technical reviews to best support acquisition decision points Risk Management monitoring and controlling of the programmatic and technical complexity associated with EA. EA Considerations and Relationships: