Establishing a Model-Based Request for Proposal (RFP) Process

Transcription

1 Establishing a Model-Based Request for Proposal (RFP) Process Lockheed Martin Mission Systems & Sensors (MS2) James Kanyok Lindsay Peterson /16/2012 1

2 Lockheed Martin s View of Model-Based Engineering (MBE) Formalizes the Practice of Systems Development Through Use of Models Modeling Across the Life Cycle Broad in Scope Includes Multiple Modeling Domains Across Life Cycle from System of Systems down to Component level Results in Quality / Productivity Improvements and Minimized Risk Rigor and Precision Communications Among Development Team and Government Management of Complexity Phase Modeling Within a Specific MBSD Encompasses Modeling at all Levels of Development Detail and Across all Phases of a System s Lifecycle 2

3 Multidisciplinary MBE Environment Matlab, C++ U(s) G(s) DOORS Rhapsody SysML Rhapsody SysML System Verif. Models (Quality Center) Legend Systems Software Hardware Shared SystemC, Verilog, ProEngineer, ANSYS S SET Q Use System Design Rationale LM Standard Rhapsody UML SEER-SEM R CLR Q Clip art used with permission by Microsoft. MBE Toolset Spans Engineering Disciplines to Integrate Requirements, Design, Development, and Implementation 3

4 MBE Advantages Drives Down Cost and Risk Promotes Full Program Understanding and Communication Provides One-Stop-Shop for System Artifacts Enhances Productivity in Full Program Life Cycle Enforces rigor and consistency in upfront engineering work Increases accuracy in engineering artifacts Promotes model, product, and analysis reuse Integrates analysis, performance modeling, requirements design, development, implementation, and I&T in one model Visually captures requirements, design, and implementation relationships Allows team to understand requirements and their relationship to the architecture Provides direct traceability between requirements, design, interfaces, analysis, and architecture Model provides single unifying record of authority for the program technical baseline Model acts as a map to all other relevant IPT artifacts, tools, models, and analyses Facilitates easy change impact analysis Houses all validation/verification information Links design and implementation through the full lifecycle Enhanced Design Accuracy and Program Communication Improves Program Affordability 4

5 Why Model-Based? Currently, there is a lack of interaction or loose connections between system design and the downstream implementation teams causing numerous design iterations, or worse, improper designs to be realized. Lack of interaction between Systems Engineering, Software Engineering, and Hardware Engineering hinders requirements flow down and allocation of top level specifications to hardware and software. MBE approach addresses current DoD concerns*: Inconsistent Application of SE Practices Across Lifecycle Insufficient Requirements Definition, Analysis, Flowdown, Management These are program failure root cause analysis findings that were presented on 2008 September 25 by Kristin Baldwin (Acting Director, Systems and Software Engineering; Office of the Deputy Under Secretary of Defense) regarding key DoD Programs 5

6 Current As-Is Request for Proposal (RFP) Process Document-Based Government Artifacts RFP, Statement(s) of Work, CDRL Lists, Attachments, Concept of Operations, Requirements all conveyed to contractors in separate documents Diagrams are imbedded in documents and can be inconsistent within documentation No guaranteed consistency from program to program Document-Based Contractor Response Contractor questions submitted in document form and separate from the original Government artifacts Contractor responses submitted through loosely connected written documents Document-Based Communication Between Government and Contractor Lacks Efficiency and Effectiveness 6

7 Current RFP Process Implications Requirements need to be converted into an electronic format If a PDF is issued, an electronic or manual conversion is required first Requirements need to be imported into a requirements management tool If the contractor is following a model-based paradigm, diagrams need to be recreated in a modeling environment Questions have to be extracted from the modeling environment to submit a document to the Government; responses have to be manually updated into the modeling tools Model-Based Contractors Must Continuously Convert Between Government Documents and Contractor Modeling Environment Clip art used with permission by Microsoft. 7

8 Model-Based RFP Possibilities: Requirements As-Is State: Government Requirements are document-based To-Be State: Requirements issued in a requirements management tool or database, potentially with SysML diagrams Benefits: Facilitates requirements management for both Government and contractor Contractor questions with regards to the requirements can be entered directly into the requirements database, allowing the Government to see all questions related to each requirement Contractor approach to implementing each requirement can be entered directly into the requirements database, facilitating Government comparison of contractor offerings from a performance perspective Requirements can be more fully depicted using SysML behavior diagrams to better describe the Government s desired intentions Using a Database to Communicate Requirements Adds Efficiency to the RFP Process 8

9 Model-Based RFP Possibilities: DoDAF Models As-Is State: DoDAF models created in drawing tools and embedded into documentation To-Be State: DoDAF models created in a SysML modeling tool Benefits: DoDAF models employ common elements from view to view, ensuring consistency Contractor questions can be electronically linked to specific DoDAF models or elements on a certain view, giving more precise context to the questions Database tool allows both the Government and the contractor to quickly see all relations to DoDAF elements across all viewpoint models Applying MBE Paradigms to DoDAF Modeling Promotes Clear and Consistent System Understanding Images from 9

10 Model-Based RFP Possibilities: Concept of Operations As-Is State: CONOPS is document-based with embedded diagrams from drawing tools To-Be State: Depict CONOPS using SysML Benefits: SysML is a standard language; every diagram element has an exact meaning SysML is a rich language, allowing for interfaces, behavior, and requirements to be depicted and interconnected to lower level design Contractors can start with Government CONOPS model, continue populating it with their proposed design, and establish electronic links to validate their design Model-Based CONOPS Conveys Precise Information in a Standard Language 10

11 Model-Based RFP Possibilities: Supporting References As-Is State: Delivered as documents To-Be State: Integrate reference documentation into requirements and architecture models with SysML Benefits: Model elements link directly to supporting references Rationale for proposed requirements, DODAF views, and CONOPS link directly to pertinent references Better communicates intent of RFP via supporting background information to the contractor If supporting document changes during RFP process, impacted requirements and DoDAF views flagged Examples: Net Ready KPP, MIL and commercial standards, training documents, trade studies, etc. Supporting Documentation integrated into the MBE approach Better Communicates Needs and Their Driving Factors 11

12 Model-Based RFP Possibilities: Contractor Deliverables As-Is State: Contractor Deliverables are Document- Based To-Be State: Contractor Deliverables include a system model depicting Contractor s proposed design Benefits: Direct electronic tracing from Contractor s proposal to the Government s RFP Enables integrated behavior, performance, and structural modeling Key design attributes can be captured within each database entry Performance Size, Weight, Power, Cost Model either complements submitted volumes or generates actual proposal volumes Government RFP Model Contractor Response Model Government RFP Model RFP Docs Contractor Docs Model-Based Contractor Deliverables Provide Government with a Thorough and Complete Understanding of Proposed Design 12

13 Overarching Road Blocks and Benefits Road Blocks Tools Compatibility between tools Implemented Features Training Both Government and Contractor will need to be trained in MBE and using MBE tools Evaluation of Proposal How does the Government ensure coverage of model in evaluation? Will evaluation only be of document based outputs? Entrenched Process This is a big shift Need to prove benefits outweigh change Benefits More precise exchange of information between contractor and government Cost reduction in execution of the RFP Improve likelihood that the system the Government specified is the system they need Model firmly established and ready Day 1 of Contract Award Clip art used with permission by Microsoft. 13

14 Conclusion A MBE-based RFP process enforces rigor and reduces cost in defining what is needed MBE emerging as an Industry best practice that improves system development MBE RFP process begins the transformation to a full MBE-based acquisition Applying the MBE SE best practice to the front of the acquisition process promotes more affordable and effective systems The Government and Contractor Community need to work together to pilot an MBE RFP approach Clip art used with permission by Microsoft. 14

15 Recommendation Pick a program to test a part of an MBE RFP Small advanced program and/or Piece of a larger program Pick an aspect of MBE to pilot Provide requirements in a model and have contractor augment it with their proposal artifacts Provide DODAF in SysML model and have contractor provide their system design model linked with the DoDAF model Consider selecting multiple large programs to pilot a single aspect of MBE or selecting one small program to pilot many aspects of MBE through the RFP process Clip art used with permission by Microsoft. 15

16