An Integrated Strategy for Acqusition Reform - PowerPoint PPT Presentation

1 / 27
About This Presentation
Title:

An Integrated Strategy for Acqusition Reform

Description:

... Cooperation Program (TTCP) is a long-standing cooperative S&T program among five ... Lt Cdr Monty Long, RN. Synthetic Environments Coordination ... – PowerPoint PPT presentation

Number of Views:60
Avg rating:3.0/5.0
Slides: 28
Provided by: jimholl
Category:

less

Transcript and Presenter's Notes

Title: An Integrated Strategy for Acqusition Reform


1
Advanced Acquisition Concepts Enabler Framework
Update
Jim Hollenbach Simulation Strategies, Inc./ U. S.
Navy Acquisition Reform Office September 2001
2001 Fall Simulation Interoperability Workshop
2
Topics
  • Review
  • Process
  • Advanced Acquisition Concepts
  • 10 Enabler Classes
  • TTCP Joint Advanced Acquisition Concepts Study
  • Current List of Required Enablers
  • Some TE aspects noted
  • Issues for the Way Ahead

3
A Framework for Collaboration
Acquisitioninitiatives
Review synthesize
Advancedacquisition concepts
Derive
List of requiredenablers
Survey assess
Enabler realizationstatus
Cross-check and iterate
Voluntarycommitmentsand statusreporting
Organizations Mission Resources Filter
Task 1
Task 2
Task 3
Task n
..
USNCHENG
DCAA
BAE
NDIA
Enabler 1
NASA
In-hand enablers made visible and available to PMs
ISO
Enabler 2
DSTO
DND
NIST
JSF
DARPA
TTCP
OMG
..
Enabler n
DERA
Dassault
Boeing
DERA
DEP
SISO
PTC
AAC Enabler WBS
4
Advanced Acquisition Concepts
  • Enterprise-wide electronic interactions and
    information sharing(info created once, used
    broadly)
  • Early and continuing collaborative exploration of
    the largest possible trade space across the life
    cycle, including time-phased requirements and
    technology insertion
  • Conceiving, designing, testing and managing to
    optimize "system of systems" attributes,
    including interoperability
  • MS-based assessments early in the development
    cycle alternative system designs built, tested
    and operated in the computer before critical
    decisions are locked-in and manufacturing begins
  • Reduction of activities more cost-effectively
    performed in MS, such as drawings, mock-ups,
    prototypes and some aspects of live testing
  • Flexible, iterative mixing of simulations and
    hardware
  • Maximum appropriate reuse of all resources -
    information, software (including COTS),
    expertise, facilities, etc. across phases,
    programs and organizations

5
Enablers Necessary Building Blocks
  • Implementing these concepts requires certain
    enablers. These requirements can be derived from
    the concepts.
  • It appears the enablers fall into 10 classes
    (categories)
  • Policy, law and organizational changes (Concepts
    A C D F G)
  • Process changes (A B C D E F G)
  • Standards for data interchange (A B C D E G)
  • Standards for software application
    interoperability (B C D E G)
  • Authoritative information sources (A B C D F G)
  • Capable, reusable models and simulations (B C D E
    F G)
  • Means to manage collaboration multi-domain
    optimization (B C D)
  • Means to identify, protect obtain reusable
    resources (A B C D E F G)
  • Business case evidence (A B C D E F G)
  • Education, motivation evolution of work force
    (A B C D E F G)

Note Well-understood and broadly available
enablers (e.g., computers, networks,
communication protocols) are omitted
6
Joint Advanced AcquisitionConcepts Study (JAACS)
  • The Technical Cooperation Program (TTCP) is a
    long-standing cooperative ST program among five
    nations Australia, Canada, (New Zealand), United
    Kingdom, United States
  • The TTCPs Joint Systems Analysis Group has
    tasked its Systems Engineering for Defense
    Modernization panel (JSA TP4) to conduct a Joint
    Advanced Acquisition Concepts Study (JAACS) that
    follows the collaborative approach described
    previously
  • This study will assess the feasibility of
    implementing advanced acquisition concepts
    proposed by acquisition enhancement initiatives
    such as System of Systems methodologies,
    Simulation Based Acquisition, Integrated Digital
    Environments, Life Cycle Planning, and
    Evolutionary Acquisition

7
JAACS Objectives
  • Provide acquisition managers
  • An understanding of the key underlying concepts
    shared by these acquisition enhancement
    initiatives
  • A comprehensive list of the enablers necessary to
    implement the concepts
  • An assessment of progress towards realization of
    those enablers, to provide insights on
    implementation feasibility, cost and risk
  • Visibility of viable enablers to encourage their
    reuse
  • Provide government, commercial and academic
    organizations active in this arena
  • Situational awareness of progress and remaining
    tasks, supporting resource allocation
  • An organizing framework for an international
    collaborative plan of work to realize the
    remaining enablers in the most affordable way

8
JAACS Study Team
  • Australian representative Mr. Rene Vandentol
  • Electronic Systems Acquisition Div., Defence
    Material Organisation
  • Rene.Vandentol_at_cbr.defence.gov.au phone 61 2
    6265 6152
  • Assistant Mr. David Marshall
  • David.Marshall_at_cbr.defence.gov.au phone 61 2
    6265 4220
  • Canadian representative Mr. Dave Madeley
  • DMASP 5-2 Systems Engineering, National Defence
    Headquarters
  • D.Madeley_at_debbs.ndhq.dnd.ca phone 613 996 2208
  • NZ representative TBD
  • UK representative Lt Cdr Monty Long, RN
  • Synthetic Environments Coordination Office
    (SECO), MoD
  • adse-rse4_at_defence.mod.uk
  • US representative CAPT Jim Hollenbach, USN
    (Ret.), chairman
  • Consultant to the Navy Acquisition Reform
    Executive, OASN(RDA)
  • jimh_at_simstrat.com, phone 703 360 3902
  • Academic advisor to JAACS Dr. Stephen Cook
  • DSTO Professor of Systems Engineering, Univ. of
    South Australia
  • stephen.cook_at_unisa.edu.au phone 61 8 8302 3818

9
JAACS Schedule
  • 1st year (June 2001- June 2002) Liaise with
    acquisition enhancement project leaders and
    interested organizations refine key concepts
    definition develop initial list of required
    enablers begin initial assessment of enabler
    realization.
  • 2nd year Develop a baseline list of required
    enablers liaise with enabler developers and
    users present study to professional societies
    and invite their review prepare a joint
    professional paper on trends in acquisition
    enhancement.
  • 3rd year Update definition of required enablers
    in light of SIAP and FOAS project insights
    refine assessment of enabler realization.

10
Current Draft List of Required Enablers
  • A first cut, subject to further analysis and
    review
  • Has not yet been documented through a structured
    requirement derivation process

11
Current List of Required Enablers (1 of 14)
  • Policy, Law and Organizational Changes(for
    processes not included within other enabler
    classes)
  • 1.1 Guidance on implementation of advanced
    acquisition environments
  • 1.2 Responsibilities and liabilities for the
    reuse of information, tools and
  • processes
  • 1.3 Contractual guidelines for information
    sharing infrastructures
  • 1.4 Contractual guidelines for MS data rights
  • 1.5 Provision to industry of the models,
    simulations and data to be used in source
    selection
  • 1.6 Designation of organizations responsible
    for SoS, mission area and/or mission capability
    management
  • 1.7 Policies for use of MS in testing
  • 1.7.1 Coordinated use of simulation and live
    testing
  • 1.7.2 Simulation prohibitions
  • 1.7.3 TE-particular accreditation criteria
  • 1.8 Policy regarding time-sharing resources
    among different organizations
  • 1.9 Designation or establishment of any
    necessary infrastructure or coordination
    organizations

12
Current List of Required Enablers (2 of 14)
  • Process Changes
  • 2.1 Recommended process for defining MS needs
    in a program and developing an MS Support Plan
    (MSSP)
  • 2.2 Recommended practices for on-line
    solicitations, proposal submissions and
    contract awards
  • 2.3 Recommended practices for use of models and
    simulations as a contractual means of
    specifying requirements
  • 2.4 Collaborative systems engineering processes
    across organizations
  • 2.5 Common security certification process

13
Current List of Required Enablers (3 of 14)
  • 3. Standards for Data Interchange
  • 3.1 Meta standards
  • 3.1.1 Tagged data format notations (e.g., XML,
    STEP Express)
  • 3.1.2 Reference discovery notations (e.g.,
    RDF, UDDI)
  • 3.1.3 Information model notations (e.g., UML)
  • 3.2 Payload standards
  • 3.2.1 Architectures
  • 3.2.2 Natural environment
  • 3.2.2.1 Physical structure
  • 3.2.2.2 Dynamic characteristics
  • 3.2.2.3 Vegetation
  • 3.2.2.4 Terrain cultural features
  • 3.2.3 Systems
  • 3.2.3.1 Physical structure
  • 3.2.3.2 Control mechanisms
  • 3.2.3.3 Support requirements
  • 3.2.3.4 Behaviors

14
Current List of Required Enablers (4 of 14)
  • 3.2.4 Humans and animals
  • 3.2.4.1 Body structure
  • 3.2.4.2 Control mechanisms
  • 3.2.4.3 Support requirements
  • 3.2.4.4 Behaviors
  • 3.2.5 Organizations
  • 3.2.5.1 Organizational structure
  • 3.2.5.2 Control mechanisms
  • 3.2.5.3 Support requirements
  • 3.2.5.4 Behaviors
  • 3.2.6 Processes (e.g. Process Specification
    Language)
  • 3.2.7 Interactions
  • 3.3 Best practices to develop enterprise-specific
    data interchange
  • standards

15
Current List of Required Enablers (5 of 14)
  • 4. Standards for Software Interoperability
  • 4.1 Standard technical architecture for run-time
    interoperability of simulations, hardware in
    the loop, and systems on ranges
  • 4.2 Standard process for simulation federation
    development and execution
  • 4.3 Standards for non-runtime application
    information exchange (e.g, data transfer
    protocols such as PDM enablers, CORBA,
    RosettaNet PIPs, etc.)
  • 4.4 Standards for discovery and use of remote
    application services
  • 4.5 Best practices for inter-relating models and
    simulations at different levels of granularity
    or fidelity

16
Current List of Required Enablers (6 of 14)
  • 5. Authoritative Information Sources
  • 5.1 Foreign military forces
  • 5.1.1 Force organization
  • 5.1.2 Tables of equipment
  • 5.1.3 Equipment characteristics and performance
  • 5.1.4 Personnel and training
  • 5.1.5 Logistics support
  • 5.1.6 Infrastructure
  • 5.1.7 Doctrine and tactics
  • 5.2 Own military forces (same seven
    subcategories as above)
  • 5.3 Reference scenarios
  • 5.3.1 Natural environment
  • 5.3.2 Civilian infrastructure
  • 5.3.3 Orders of battle
  • 5.3.4 Design reference missions
  • 5.3.5 Operational situation

17
Current List of Required Enablers (7 of 14)
  • 5.4 Information about system under development
  • 5.4.1 Missions and tactics
  • 5.4.2 Structure
  • 5.4.3 Behaviors
  • 5.4.4 Operators
  • 5.4.5 Reliability
  • 5.4.5 Maintainability
  • 5.4.6 Logistics support
  • 5.5 Costing relationships and methods
  • 5.6 Manufacturing capabilities
  • 5.7 Emerging technology

18
Current List of Required Enablers (8 of 14)
  • 6. Capable, Reusable Models and Simulations
  • 6.1 General MS use guidelines
  • 6.2 Standard, reusable MS environments and
    associated metrics (stand-alone models and
    simulations, and persistent simulation
  • federations)
  • 6.2.1 System effectiveness
  • 6.2.1.1 Strike warfare, including time critical
    strike
  • 6.2.1.1.1 Campaign level
  • 6.2.1.1.2 Mission level
  • 6.2.1.1.3 Engagement level
  • 6.2.1.1.4 Engineering level
  • 6.2.1.2 Suppression of enemy air defenses
    (appropriate granularities continue for each
    mission area)
  • 6.2.1.3 Air defense
  • 6.2.1.4 Ballistic missile defense

19
Current List of Required Enablers (9 of 14)
  • 6.2.1.5 Land warfare
  • 6.2.1.6 Naval warfare
  • 6.2.1.7 Reconnaissance, surveillance, and target
    acquisition (RSTA)
  • 6.2.1.8 Close air support and fire support
  • 6.2.1.9 Military operations in urban terrain
    (MOUT)
  • 6.2.1.10 Information warfare
  • 6.2.2 Logistics
  • 6.2.2.1 Requirements
  • 6.2.2.2 Air lift
  • 6.2.2.3 Sea lift
  • 6.2.2.4 Ports
  • 6.2.2.5 In theatre
  • 6.2.3 Cost
  • 6.2.4 Common federation support tools

20
Current List of Required Enablers (10 of 14)
  • 6.3 Inventory and assessment of other models,
    simulations and federations
  • (6.3.1 through 6.3.4 same taxonomy as above, plus
    system-specific logistics models)
  • 6.3.5 Functional allocation (requirements
    tracing)
  • 6.3.6 System architecture
  • 6.3.7 Computer aided design (CAD/CAM)
  • 6.3.8 Visualization tools
  • 6.3.9 Manufacturing/assembly
  • 6.4 Best practices for modifying models and
    simulations
  • 6.5 Best practices for procuring models and
    simulations
  • 6.6 Best practices for developing models and
    simulations
  • 6.7 Standard verification, validation and
    accreditation (VVA) procedures, including
    documentation

21
Current List of Required Enablers (11 of 14)
  • 7. Means to Manage Collaboration and Multi-Domain
    Optimization
  • 7.1 Project management tools (WBS, schedule,
    earned value, etc.)
  • 72. Human interaction means (VTC, virtual
    presence, groupware, etc.)
  • 7.3 Digital signature and electronic delivery
    verification means
  • 7.4 Cross-application optimization methods and
    tools
  • 7.5 Decision support software tools
  • 7.6 Decision rationale capture means

22
Current List of Required Enablers (12 of 14)
  • 8. Means to identify, protect and obtain reusable
    resources
  • 8.1 Resource management systems
  • 8.1.1 Product data/information management
    (PDM/PIM) systems
  • 8.1.2 Distributed resource repositories
  • 8.1.3 Bulletin boards
  • 8.1.4 Enterprise resource management/planning
    tools
  • 8.1.5 Help desks
  • 8.2 Access control means
  • 8.2.1. Protection means for classified,
    proprietary or private resources
  • 8.2.2 Procedures for the release and delivery
    of resources to qualified users
  • 8.2.3 Appeal/dispute adjudication policy
  • 8.3 Encrypted transmission services
  • 8.4 Incentives for resource developers/owners to
    make their resources available
  • 8.5 Population of 8.1 with resources or resource
    descriptions w/POCs

23
Current List of Required Enablers (13 of 14)
  • 9. Business Case Evidence
  • 9.1 Cost benefit analyses for electronic
    interactions
  • 9.2 Cost-benefit analyses for information
    sharing
  • 9.3 Cost-benefit analyses for whole life
    approaches
  • 9.4 Cost-benefit analyses for system of systems
    management
  • 9.5 Cost-benefit analyses for MS use
  • 9.6 Otherwise impractical MS benefits (e.g.,
    overcoming safety or security constraints on live
    operations)
  • 9.7 Cost-benefit analyses for MS reuse
  • 9.8 Commercial marketplace trend analysis
  • 9.9 Methods to combine and extrapolate
    cost-benefit analyses

24
Current List of Required Enablers (14 of 14)
  • 10. Education, motivation and evolution of work
    force
  • 10.1 Means to identify AAC-related professional
    qualifications
  • 10.1.1 Individuals
  • 10.1.2 Organizations (CMMI extension?)
  • 10.2 Educational source material
  • 10.3 Education delivery means
  • 10.4 Education opportunity awareness means
  • 10.5 Motivation of the work force
  • 10.6 Management means to shape the work force

25
Some Challenges
  • Methodology and tools for derivation of required
    enablers
  • Assessment of nominated enablers
  • Progress quantification
  • Identification of dependencies
  • Feasibility/risk assessment mechanism
  • Enabler workarounds
  • Change recommendation adjudication
  • Soliciting additional manpower and delegation of
    enabler class responsibility

26
Issue Derivation of Required Enablers
  • We need to establish a disciplined, defendable
    methodology for identifying required enablers
    (and defending against bad assertions)
  • A standard systems engineering process would be
    optimal
  • There will be alternate ways to enable some AACs
    we must identify these, weigh them, and identify
    both the optimal enabler and alternate
    workarounds
  • E.g.,, tool interoperability standards vice
    standard tools
  • We need to account for variations in the firmness
    (confidence level) and importance of individual
    enabler requirements
  • The extent of the enabler list (200?) and the
    fact that many enablers will support multiple
    AACs means this is going to get complex
  • Thus far I have been trying to use Microsoft
    Excel to track enablers because it is widely
    available and avoids the expense of having to buy
    another software application
  • We may need to use a specialized requirements
    traceability tool such as DOORS or CORE

27
Discussion
Write a Comment
User Comments (0)
About PowerShow.com