1 / 14

A Perspective on System Engineering – Delivering Capabilities

A Perspective on System Engineering – Delivering Capabilities. 16 Feb 05 Dave Jacques Chief, Education and Training. The Need.

yetty
Download Presentation

A Perspective on System Engineering – Delivering Capabilities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Perspective on System Engineering – Delivering Capabilities 16 Feb 05 Dave Jacques Chief, Education and Training

  2. The Need “As DoD enters into an era of Net-Centric Operations and Warfare(NCOW),the ability to portray and understand complex many-to-many relationships becomes even more important.Capabilities must be able to“plug and play” in a Joint, global, multimedia, and multilingual environment. To achieve this ability,there must be a mechanismfor incorporating information technology consistently, controlling the configuration of technical components, ensuring compliance with technical “building codes,” and ensuring efficient processes.Architectures provide this mechanismby serving as a means for understanding and managing complexity.” - DOD Architecture Framework, Version 1.0, Volume 1, p. 3-5, August 2003

  3. The Process • Traditional SE process focused on system design • Sequential, with clearly defined steps, milestones and feedback loops • Complexity of Systems-of-Systems demands an architecture based approach • Facilitates integration and interoperability • More complex up front • Users, acquirers, and developers must work together at all stages

  4. Overarching Policy NSS/NMS/Joint Vision DOD 5000 Series Acquisition Management Framework Joint Concept of Operations Functional Area Analysis Functional Area Functional Concept Integrated Architecture Feedback MS B D O T M L P F MS C Analysis of Material Approaches - Material - Process CDD MS A CPD DOTMLPF Process AoA JROC DAB ICD Concept Refinement CD JROC DAB Technology Development JROC DAB Increment 1 Demo MS C MS B Increment 2 Demo MS C MS B Increment 2 Demo DoD Acquisition Process Sustainment Joint Capability Integration and Development Systems (JCIDS)

  5. CPD Functional Area Joint Functional Concepts Integrated Architectures Functional Area Analysis CDD Functional Needs Analysis ICD Functional Solution Analysis D O T M L P F Post Independent Analysis Analysis of Material Approaches Alternative 1 Alternative 2 Material Changes CJCSI 3170 Process Ideas for Material Approaches DOTLPF Change Recommendation DOTLPF Changes CJCSI 3180 Process Joint Capability Analysis Strategic Policy Guidance

  6. USMC Battlespace Awareness Architecture USAF Service Concepts USN Command and Control Architecture USA Force Application Architecture Battlespace Awareness Command and Control Force Application Protection Logistics Protection Architecture “slice” represented by an integrated architecture Logistics Architecture Functional Concepts Joint Operating Concepts Joint Integrated Architecture Homeland Security Major Combat Operations Strategic Deterrence Stability Operations Operating and Functional Concepts

  7. The Operational View describes and interrelates the operational elements, tasks and activities, and information flows required to accomplish mission operations. Operational Operational View View Systems Systems The Systems View describes and interrelates the existing or postulated technologies, systems, and other resources intended to support the operational requirements. View View The Technical View describes the profile of rules, standards, and conventions governing systems implementation and forecasts their future direction. Technical Technical View View DoD Architecture FrameworkOne Architecture – Three Views

  8. OPERATIONAL (OV) SYSTEMS (SV) TECHNICAL (TV) 1: High-Level Operational Concept Graphic* 1: Systems Interface Description* 1: Technical Standards Profile* 2: Systems Communications Desc.* 2: Operational Node Connectivity Description* 3: Systems-Systems Matrix 3: Operational Information Exchange Matrix* 2: Technical Standards Forecast 4: Systems Functionality Description 4: Organizational Relationships Chart 5: Operational Activity to System Function Traceability Matrix 5: Operational Activity Model* ALL (AV) 6: Sys Data Exchange Matrix* 6a: Operational Rules Model Overview & Summary* 7: Sys Performance Parameters Matrix 6b: Operational State Transition Description 8: Systems Evolution Description Integrated Dictionary* 6c: Operational Event/Trace Description 9: Systems Technology Forecast 10a: Systems Rules Model 7: Logical Data Model 10b: Systems State Transition Desc. 10c: Systems Event/Trace Desc. 11: Physical Data Model DoD Architecture FrameworkProducts * Denotes critical products Spreadsheets Static Models & Graphics Text DynamicModels CADM: Core Architecture Data Model

  9. SE and Architecture throughout the Life Cycle • Technology R&D • Basic research – revolutionary concepts • Integrated architectures - evolutionary concepts • Capabilities Generation • Architectures – capability, interoperability needs • Analysis of Material Approaches – BIG system trade studies/analysis • Aircraft vs. cruise missile vs. long range artillery etc.

  10. SE and Architecture throughout the Life Cycle (cont’d) • Concept Refinement/Technology Development • Analysis of Alternatives – LITTLE system trade studies • Technology demo – risk management • Integrated architectures – SoS interoperability • Capabilities  System requirements • System Development & Demonstration • System requirements  System developed/modified/verified • SoS Needs  Capability developed/validated

  11. The Challenges • Tools • Architecture evaluation – must ensure correctness, completeness, concordance • Concept validation – requires executable models • Decision analysis models – required to support acquisition decisions • People • Need technically educated, systems-focused operators • Need to replenish aging acquisition workforce • Both require SE understanding and discipline • Leadership • Clear, consistent policy and guidance throughout DoD • Follow-through on implementation and adherence • Accountability across all levels

  12. Architecture-Based Analysisand Decision Making • Structure • Functions/Actors/ Nodes/Products for operational needs and Portfolio Resources for fulfilling them • Relational models drawn from databases in format of lists or matrices • Time Ordered • Behavior in the form of rules, state transitions and sequences • Lends itself to representations as graphs • Time Scheduled • Adds constraints including time, environment and resources • Can be represented by discrete event simulation, time-queued operations • Time Functional • Adds the notion on continuous time functionality, often in conjunction with external, continuous time representations • Truly dynamic functionality based on “time continuous” models that dominate the simulation world Levels of Architectural Description

  13. Levels of Architectural Models

  14. Summary • Implementation of capability-driven, architecture-based processes is a journey • SE discipline and accountability required • Educational opportunities in SE are expanding to meet the needs

More Related