Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Don Schaefer – 703.984.3388 Mission Engineering TM - a transformational business analysis and system engineering approach Challenge the Dominant Paradigm.

Similar presentations

Presentation on theme: "1 Don Schaefer – 703.984.3388 Mission Engineering TM - a transformational business analysis and system engineering approach Challenge the Dominant Paradigm."— Presentation transcript:

1 1 Don Schaefer – Mission Engineering TM - a transformational business analysis and system engineering approach Challenge the Dominant Paradigm

2 2 Don Schaefer – Mission Engineering (ME) Defined ME is an advanced requirements gathering and analysis method ME is focused on capturing & translating the intent of the customers mission needs into implementable system/software/data requirements ME reduces interpretation of textual requirements by using visually robust products as the central communication device ME provides notational linkage of the implementable requirements to the originating customer mission needs ME is an engineering method that can be used with any system or software engineering processME is a repeatable method where all of the processes and artifacts can be used, or it can be tailored with only a subset of the overall method ME analysis and artifacts support acquisition analysis, BOE costing and portfolio management. ANALYSIS, COMMUNICATION & UNDERSTANDING

3 3 Don Schaefer – Why Was Mission Engineering Developed? Deliver systems with greater user satisfaction Speed up design and development time Provide analytical defendable traceability from customer need to architecture design Provide a better way to derive/illustrate COTS/GOTS/Technology integration requirements Identify the risk…technical, operational and programmatic Provide a more integrated and holistic view of the enterprise Customers spend millions of dollars…purchase the best hardware, the best software, and the best engineers…and if the users dont like or use the system…the system development was a failure

4 4 Don Schaefer – Mission Engineering and the DODAF Pyramid Operational View Identifies What Needs to be Accomplished and Who Does It Technical Standards View Prescribes Standards and Conventions Systems View Relates Systems and Characteristics to Operational Needs Specific System Capabilities Required to Satisfy Information exchange Technical standards Criteria Governing Interoperable Implementation/Procurement of the Selected System Capabilities Systems that Support the Activities and Information Exchanges What Needs to Be Done Who Does It Information Exchanges Required to Get It Done Operational Requirements and Capabilities Basic Technology Supportability New Technical Capabilities

5 5 Don Schaefer – Community SPECIFICATION ARCHITECTURE DESIGN OPERATIONS DEPLOYMENT VERIFICATION INTEGRATION Mission Engineering Systems Analysis Multiple Dimensional Requirement's Reqts Mapping to Activities Derive Requirements Risk Analysis Requirement's Visualization Operational Scenarios Community Feedback Launch & Learn via Portal ACQUISITION / CONSTRUCTION DEVELOPMENTTEST INPUT To… Field Documentation (Manuals) Training Material Development INPUT To… Fault Isolation Problem Isolation Program Office INPUT To…Detail Design Actor Inventory Visualization & GUI design Use Case Description Activity / Sequence / etc…UML COTS/GOTS/Custom Code Integration Opportunities Business Rule Conflict Risk Areas & Opportunities Prioritization of EAR - Activities Community Analysis Community Model Interface Transaction Inventory Visual Con Ops Advocacy Products - CV Community Client Information Existing Ops Cons & Req Legacy systems Constraints INPUT To… ICD Identification Actor/Organization Interfaces CONCEPT Operations Analysis Enterprise Activity Roadmap Concept Visualization Mission Process Mapping Technology Mapping INPUT To… COTS/GOTS Integration INPUT To… Test Plan & Procedures Used To… Validate design

6 6 Don Schaefer – Mission Engineering – What it will do, what it wont do Mission Engineering WILL: –Provide your program with enough functional requirements and preliminary design content to get you to your programs Preliminary Design Review (PDR) gate –Provide your program with a conceptual design of the system/application –Provide your program with high level business process flows that are linked to requirements –Provide data architects with a preliminary first draft data dictionary –Provide software architects with a complete workflow analysis, functional behaviors and interface points for COTS integration –Provide Business Process Analysts with lower level (level 5) process flows and business rules –Provide Test engineers with a first draft of the system test procedures –Provide Test engineers with multiple Mission and Capability functional threads –Provide Trainers with input to both standup and/or computer based training course material development –Provide system engineers and architects with preliminary interface definitions and architectural behaviors –Provide stakeholders (Customers) with an easily understood view of what will be developed and how it will be used –Provide your program high quality, rigorous, analytical business and engineering content…if you have the right team Mission Engineering will NOT: –Provide your program with detailed design; e.g. logical model, physical model, UML –Provide you with system level requirements; e.g. –ilities (maintainability, scaleability, etc), network protocals, etc Provide you with hardware requirements Provide you with network requirements, etc –Be useful to the program if you do not have the right team working on the analysis.

7 7 Don Schaefer – Customer Need Engineering Reqts ANALYSIS, COMMUNICATION & UNDERSTANDING Phases of Mission Engineering

8 8 Don Schaefer – INPUTS Goals Processes Products Existing Documents User Types Core Products Community Interface Model Transaction Inventory Actor Inventory Background Information Additional Products Visual Operations & Requirements Spec Concept Visualizations Advocacy Material Requirements Standardized Architectural Views e.g. C4ISR Value Engineering TEAM Customer Domain Analysts Mission Eng Analyst Desktop Multimedia Producer Input To: Arch Analysis Program Marketing Training Reqts Analysis ICD Development Mission Engineering Phase I – Community Analysis Process

9 9 Don Schaefer – Transaction ID Develop Information Transaction Inventory Info Sent From Info Received From When transacted Info Type Network Domain EAR Service Area EAR Activity ME Traceability Develop Community Model Analyze and Define: Mission Customers, Mission Partners Mission Roles: Analyst, Consumer, Collection Manager Information transactions Information developed & delivered among roles Value Chain & Capabilities Develop understanding and advocacy for Customer's Goals and Transformation Develop Concept Visualization Community Analysis – Advocacy & Understanding

10 10 Don Schaefer –

11 11 Don Schaefer – Phase 1 Summary of content At this point, we should have developed: –First draft of community model –Beginning of the actor list –Beginning of the tools (COTS/GOTS) list –Supplier list –Customer list –Partner list –Information Transaction table –TIME Elapsed: 1 to 3 weeks Additionally, if the program desires, we should also begin the story board for the concept visualization work

12 12 Don Schaefer – Core Products Enterprise Activity Roadmap Activity Goals & Descriptions Capability Descriptions Enterprise Activity Function Map Mission Process Models Additional Products Business/Mission Process Analysis Technology Evaluation Matrix Mission Threads/Product Threads Actor and Activity Matrix Requirements Analysis C4ISR Views TEAM Customer Domain Experts Business Analysts Mission Eng Analyst Information Architect System Arch Output To: Community Model Updates ME Phase 3 BPR activities Program Marketing Strategic Acquisition Mission Engineering Phase II – Operations Analysis Process

13 13 Don Schaefer – Work with stakeholders on the mission of the organization and the product & service value chain scenarios from a task flow perspective. Identify high level Mission or Operational Service Areas Identify functional activities involved within the system workflow…logical groupings Create an inventory illustrating the actor functional activities required in the performance of their mission or in production of a product or service The Enterprise Activity Roadmap is developed in an Integrated Product Team environment

14 14 Don Schaefer – Increment 1 Increment 2 Increment 3 Operational Services Functional Activities Activity Name: Activity Code: Actor Class; Actor: Pre-: Post-: COTS/GOTS: Arch service: Source: Enterprise Activity Roadmap defined… Commercial Tool A Commercial Tool B Legacy App 1 No Tool ID

15 15 Don Schaefer – Functional Breakdown of COTS/GOTS tools There are two ways to map tools to the activity roadmap; complete tool or tool function. For instance, in the illustration below, lets assume the yellow icon represents the Microsoft Office Tool. –As the MS Office tool, you can see exactly what activities have been identified that the MS Office tool will be used or integrated. –Or, if you break MS Office into its high level component functions, (e.g. , Notes, Tasks, Contacts, Calendar), you would see which activities will use MS Office, but, you could also then see which component of MS office as well. –You would have: OL-C – outlook-calendar OL-E – outlook- OL-N – outlook-notes Add COTS/GOTS component as an attribute to activity

16 16 Don Schaefer – Mission Process Map (MPM) Overview Service Area Identifier A Mission Process Map (MPM) shows the BPR results in the context of a Mission thread. The steps in the MPM are mapped directly to the Activities in the Roadmaps and Service Areas in the Community Model Activities mapped to the Roadmap

17 17 Don Schaefer – Phase 2 Summary of content At this point, we should have: –First draft of every enterprise segment activity roadmap –Full definition of each service area –Written all goals and descriptions for all activities –Begun to prioritize the activities per client needs, implementation schedule and funding –A number of Mission Process Maps completed, may include state changes –A candidate set of Capability Vignettes completed or identified –Full description of each actor role –Mapped actor roles to activities –Functional breakdown of tools –Mapped Tools/functions to activities –Listed source for each activity, e.g. document, legacy, person –Final draft of the Community model with Service areas shown –TIME Elapsed: 2 to 6 weeks

18 18 Don Schaefer – Core Outputs Functional Requirements Data Elements and Attributes Multidimensional Requirements View Data Tables/Relationships Business Rule to Function Mapping Additional Outputs System Requirements Enterprise Requirements Documents Business Process Analysis Requirements Mapping Requirements Traceability Matrix Requirements Visualization Information Architecture Output To: Tool Evaluation Testing Procedures Training Architecture Field Documentation SW Detailed Design DB Design BPR TEAM Domain Experts Architects – SW, DB, SYS, SEC, Info Mission Eng Analyst Mission Eng Facilitator Mission Engineering Phase III – Systems Analysis Process

19 19 Don Schaefer – Multi-Dimensional Requirements View (MRV) Created in an IPT environment of stakeholder, developers and integrators Captures the activity workflow of people and systems Captures the behaviors between functions, applications and data Derives new requirements from integrated architecture analysis Provides framework to map existing legacy requirements Requirements Visualization EAR Activity Service Area Web viewable; DOORS, RequistPRO Central Repository Define operational functional steps – activity workflow Map ops functions to system layer applications Map data created & data read to functions Derive new requirements, map existing requirements Derive and/or Map business rules to functions MRV System Requirements – Workflow, Interfaces, Behaviors

20 20 Don Schaefer – MRV SET….For each functional activity…

21 21 Don Schaefer –

22 22 Don Schaefer – MRV to RV development…test drive the requirements prior to development

23 23 Don Schaefer – MRVs explained & link to rest of program Business Segment User Role Business Segment Activity Business Segment Service Area Activity Functional Steps Architecture Segments – Application COTS/GOTS interface Data Store Name – Read / Write Activity Functional Requirements Activity Function Business Rules Maps Activity / Requirements to Capabilities on CDR Criteria for Tech Evaluation Input to Software Design Input to Test Procedures Input to Training Scenarios Input to User Experience Input to Information Architecture Input to TE Business Process Analysis DOORS Database

24 24 Don Schaefer – Phase 3 Summary of content At this point, you should: –Begin development of the integrated Ops and Requirements Document –Completed a first draft of the prioritized MRVs –Defined performance goals for each MRV to the level required –Can begin development of the data dictionary from each MRV –Analyze the COTS/GOTS functional interfaces for integration –Updated the Community model –Updated the Activity Roadmaps –Updated the Business process flows –TIME Elapsed: 1 to 3 MRVs per day

25 25 Don Schaefer – The Linkage Activity Missile Defense Mission Thread CSCs Multidimensional Requirements View (MRV) Perform Ballistic Missile Optimization ACT Code: OP-PBMOP Actor: PA, PL Arch CSCI: OPTIMZ COTS/GOTS: ILOG, IMEA, JMEM, MEM, MGPS Mission Ops Activity Roadmap 0042 Deliver Basic Detailed Planning Optimization Community Model Requirements to Architecture View (RAV) MCP

26 26 Don Schaefer – Users validate Information Architecture Users work with Geoscout to determine activity and service needs Stakeholder Insight User Groups from NGA Mission Segments; GIO, Corp, Funct, ITM NGA Community Model Activity Roadmaps Users drive Ops function needs in MRV-member of design team Users support Business Process Analysis & Mission Process Mapping Business Processes from each Mission Segment Activity Mapping to Mission Threads & Business Processes Requirements Viz & Tech Demos Users evaluate prototypes and tools Multidimensional Requirements View (MRV) NSGI Site Map 1 for 1 relationship of user activity to MRV Communications

27 27 Don Schaefer – INPUT PRESENTATION & ANALYSIS OUTPUT Legacy System Requirements User & Stakeholder Input Developer Input & Ideas User Validated Operational Concept Requirements Validation: Mapping Requirements to Functionality Risk Identification Training Input Information Architecture Test Plan & Procedures BPR Tasks Technology Evaluations Use Case Input Activity Diagrams Sequence Diagrams Business Objects Etc… Interface Design Deferred / Derived Requirements Strategic Analysis Business Cases Capability Value Chains Converting Needs into Requirements, Communicating Results Mission Engineering Summary

28 28 Don Schaefer – ClientProject NameClientProject Name NGAIntegrated Exploitation Capability (IEC) NROXOComm Air Force Space Based Blue Force Tracking NGABig Idea DISATraces2NSAStone Mason Joint Staff Airborne ISR Requirements Based Allocation DIAHUMINT/CI Comms Architecture Eval DIAJIVADISAMeteorological Info System Terminal (MIST) SPAWARStrike Fighter Training System (SFTS) NGAGeoScout Booz Allen Has Successfully Applied Mission Engineering to a Wide Range of Clients and Products

29 29 Don Schaefer – Value and benefits of using Mission Engineering Fosters Communication and Understanding Translates mission needs into engineering requirements Reduces interpretation of textual requirement Illustrates user functions within work flow Illustrates COTS/GOTS/Custom code integration/interfaces Supports the early identification of risk; technical, business and program Supports product/artifact reuse across the system/software engineering lifecycle Support the development of test and training material Supports development of DODAF views

Download ppt "1 Don Schaefer – 703.984.3388 Mission Engineering TM - a transformational business analysis and system engineering approach Challenge the Dominant Paradigm."

Similar presentations

Ads by Google