Sign In
  • Question

    Agile and DevSecOps focuses of working software vice documentation. What is the minimal set of system documentation required by the DOD that a AIS program (e.g., ACAT III, non-ACAT) must produce and maintain. For example: System Subsystem Design Description, Software Requirement Specification, Software Design Description, Interface Requirement Specification, Interface Design Description, Software Test Plan, Software Test Description, Software Test Report, Logical and Physical Data Models, Database Design Description, etc. Thank you in advance.


    Answer

    One of the Agile values is that working software is of greater value than comprehensive documentation.  Note that it does not mean that documentation offers no value, just that it is seen as less valuable than working software. 

    There following references will help to answer your questions about documentation requirements a PMO is required to submit to the MDA, and also the documentation a contractor is required to submit to the Government. 

    1. AIR FORCE INSTRUCTION 63-101/20-101, 30 JUNE 2020, Acquisition/Logistics INTEGRATED LIFE CYCLE MANAGEMENT, COMPLIANCE WITH THIS PUBLICATION IS MANDATORY
      1. See Section 3.8, Development RFP Release Decision. To meet the intent and criteria of the Development RFP Release Decision, ACAT ID and ACAT IAM programs do not have a separate AF Review Board and Acquisition Strategy Panel for programs where OSD is the MDA. The AF conducts a combined Acquisition Strategy Panel and AF Review Board with no further review prior to the MDA holding the review. The PM ensures provisions for small business utilization are considered in the RFP and source selection criteria as practicable. More information and a RFP template can be found on the AF Portal at the “SAF/AQXE - Execution/Oversight” page in the Secretariat/Air Force Review Board section. Other than the Acquisition Strategy, planning documentation may be in approved draft format, per Chapter 4, for this review.
    1. DODI 5000.75 BUSINESS SYSTEMS REQUIREMENTS AND ACQUISITION, January 24, 2020
      1. See Table 4, Statutory Requirements
      2. See Section 4.1.l, Overview, DOCUMENTATION AND DELIVERABLES.  Information requirements will generally not be prepared solely for staff review and approval. In addition to supporting decision making at ATP decision points, these products should support program activities such as contracting actions or test events, or serve as planning and management tools. The information produced will be specific to each program and acquisition information (e.g., acquisition strategy content) will be tailored to meet individual program needs. Details will be maintained by the program in a transparent and timely manner, readily available for reviews as needed.
         
    2. DODI 5000.87, OPERATION OF THE SOFTWARE ACQUISITION PATHWAY, October 2, 2020
      1. The Government is responsible to generate the following planning documents:
        1. Capability Need Statement
        2. User Agreement
        3. Acquisition Strategy
        4. Cost Estimates
      2. Page 9, GENERAL PROCEDURES, “The PM and applicable stakeholders will identify, and the DA will approve, a transition approach to tailor processes, reviews, and documentation to effectively deliver software capabilities.”
      3. Page 11, ACQUISITION STRATEGY, “Consistent with modern software development practices, the acquisition strategy and related program documentation will be tailored to what is needed to effectively manage the program.”
      4. Page 11, ACQUISITION STRATEGY, “The DA will approve the acquisition strategy to include process and documentation tailoring.”
      5. Page 13, IP STRATEGY, “The PM will implement mechanisms to ensure any restrictive markings on software and software documentation deliverables markings and assertions conform to contract terms and conditions before acceptance by the government.”
      6. Page 14, IP STRATEGY, “The PM should require delivery of all the source code for software developed at the government expense, including all software capability descriptions (e.g., features, story points, use cases) and all as-built architecture and design products, traceability products, interface definitions including interfaces to proprietary software elements, and any other requisite documentation.”
      7. Page 18, Each program will develop and track a set of metrics to assess and manage the performance, progress, speed, cybersecurity, and quality of the software development, its development teams, and ability to meet users’ needs. Metrics collection will leverage automated tools to the maximum extent practicable. The program will continue to update its cost estimates and cost and software data reporting from the planning phase throughout the execution phase.
         
    3. Milestone Document Identification tool (MDID) helps acquisition personnel identify statutory and regulatory program information requirements, as referenced in DoDI 5000.85 and DoDI 5000.81:
      1. Milestone and phase information requirements
      2. Acquisition Program Baselines (APB)
      3. Statutory program breach definitions
      4. Recurring program reports
      5. Exceptions, waivers, and alternative management and reporting requirements
      6. Cost and software data reporting (CSDR)
      7. Earned value management system (EVMS) application requirements
      8. EVMS reporting requirements
      9. Actions associated with Clinger Cohen Act compliance
      10. Information Requirements Unique to the Urgent Capabilities Acquisition Process
         
    4. AGILE AND EARNED VALUE MANAGEMENT: A PROGRAM MANAGER’S DESK GUIDE, OUSD(A&S), 17 NOVEMBER 2020
      1. Agile Metrics and EVM Metrics, “As with the discussion on definitions, there are no DoD standards for Agile methodology metrics. Metrics such as velocity, burn-down/burn-up, etc. must be agreed upon by the performing contractor and the government PMO.”

    Open full Question Details
Chat with DAU Assistant
Bot Image