Proposal Development

Software Proposal Evaluation

The Source Selection Evaluation Team (SSET) evaluates each offeror‘s proposal and any subsequently submitted information or proposal revisions against the solicitation requirements and evaluation criteria. The SSET evaluates the offeror‘s understanding of the software task, the viability of the proposed approach, and the offeror‘s capability and capacity to perform. In addition, the SSET identifies and documents the strengths, deficiencies, uncertainties, weaknesses, and risks associated with each offeror‘s proposed approach.

During source selection, the SSET should typically accomplish the following software-related activities: [1]

  • Review and evaluate the offeror‘s CS&S architecture, including all software to be developed, reused, and integrated, to ensure solicitation requirements can be satisfied.
  • Evaluate the completeness and soundness of the proposed technical approach to meeting computer systems and software requirements.
  • Evaluate for realism the size of the proposed software development and integration effort, considering expected software size growth during development, proposed software reuse, proposed modification to existing software, proposed use of Software Commercial off-the-Shelf (COTS) products, and other software development and software integration risks.
  • Determine that the software size, technical content, development effort (cost), and schedule has been appropriately and consistently addressed throughout the proposal (for example, ensure the size of the software proposed in the technical volume is reflected in the cost volume).
  • Develop a conservative estimate of the required software development effort based on the proposed software size and development approach, and crosscheck this estimate:
    • If the SSET estimate shows that the proposed effort is not adequate, adjust the Most Probable Cost (MPC).
    • Develop a conservative estimate of the required software development schedule based on the proposed software size and development approach, and crosscheck this estimate:
    • Assess the software schedule risk in the context of the proposed Integrated Master Schedule (IMS), including software-related IMS task durations, sequencing, and linkages.
    • If the SSET estimate shows that the proposed software development schedule is not adequate, provide inputs to a schedule risk assessment so that any resulting schedule extension can be dollarized and integrated into the MPC.
  • Evaluate the proposed software development and integration processes as defined in the proposed Software Development Plan (SDP).
    • Expect to see evidence of established processes in a company standard development approach, reflected in the program SDP.
    • Evaluate adequacy of and commitment to consistently apply the proposed processes through the SDP, Integrated Master Plan (IMP), Integrated Master Schedule (IMS), and Statement of Work (SOW). (Commitment to processes must be established from the beginning of the contract, across the development team. Required software activities and tasks should be clearly addressed and the temporal (sequential and concurrent) relationships of these activities should be clearly indicated. Event completion criteria should include relevant software engineering process steps. Engineering analysis should be performed to determine that the IMS reflects adequate time to apply the proposed software development processes.)
    • Evaluate the compatibility of the proposed software development processes with the proposed software effort, schedule, and performance baselines.
    • Evaluate the integration of software engineering within Systems Engineering.
  • Evaluate the proposed approach to identifying and managing computer system and software risks, and assess the initial risks and mitigation activities identified by the offeror’s.
  • Evaluate the proposed approach for software activity planning and statusing, including the use of software metrics.
  • Evaluate the proposed approach for software problem reporting, tracking, and resolution.
  • Evaluate the proposed approach for software sustainment planning.
  • Evaluate the block/incremental development approach, and ensure that adequate personnel, development stations, and integration labs are available to support any planned concurrent development.
  • Ensure that any proprietary rights or intellectual property issues are identified, and that appropriate rights are proposed based on the expected operational and support approaches for the software.
  • Ensure that offeror’s propose an adequate approach to testing/verifying Government Furnished Software (GFS) well prior to need, and that offeror’s understand such software is provided ―as-is.
  • Evaluate the proposed approach to managing software suppliers, including flow-down of performance and process requirements, use of common development environments, balance of subcontract type and risk, and approach to insight, communication, and control.

– See Software Source Selection Considerations
– See Software RFP Content

AcqLinks and References:

Updated: 7/27/2017

Leave a Reply