bannerb

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

7.3 - Acquisition Guidance

1. Purpose

This topic discusses guidance for projects implementing those requirements in NASA Procedural Requirement (NPR) 7150.2, NASA Software Engineering Requirements that address software acquisition. This guidance is intended for all persons responsible for the software acquisition process, from the planning stages through contract closeout. Acquisition may involve procedures and regulations external to the software community, including variations by contract type; therefore, it is important to consult Center guidance and coordinate acquisition activities among the proper stakeholders, including, but not limited to, software engineering, procurement, finance, and contracts.

1.1 Roles

Role

Responsibility

Project Manager

Approve procurement plan.

Software Lead Engineer

Prepare procurement plan; prepare statement of work (SOW) software requirements and software data requirements for the contract; monitor execution of contract; conduct trade studies, engineering analyses.

System Engineer

Conduct trade studies, engineering analyses.

Contracting Officer (CO)

Prepare acquisition approach, prepare solicitation, guide proposal evaluation, prepare contracts, prepare modifications to contracts.

Contracting Officer's Representative (COR)

Work with CO to plan acquisition approach, prepare SOW, evaluate proposals, determine the technical adequacy of proposed approach, monitor technical implementation.

Software Technical Authority

Before contract release, verify that the SOW includes the complete flowdown of the Agency and Center software requirements [recommended practice].

2. Planning

Before software acquisition can be carried out, a need must be identified for which a solution is required.  During the planning stage, various options to address the identified need are evaluated.  The following are possible options:

  • Acquire off-the-shelf (OTS) product.
  • Develop/perform service in-house (make/buy decision).
  • Contract development/service.
  • Use/enhance existing product/service (consider reuse of existing software components for applicability to project).

If the solution to the need will involve software, NPR 7150.2 applies, and the acquisition planning guidance below supports project success:

  1. Define the scope of the system of interest.
  2. Identify the goals and objectives for the software portion of the system.
  3. Identify key stakeholders.
  4. Perform “make or buy” market research/trade studies to determine if an

    <ac:macro ac:name="unmigrated-wiki-markup">
    <ac:plain-text-body><![CDATA[

    OTS

    ]]></ac:plain-text-body>
    </ac:macro>

    solution exists.
  5. Establish criteria (and a plan) for the studies:
    • Technical requirements (functional, operational, performance):
    • NPR 7150.2 classification.
    • Constraints and limitations (cost, schedule, resources).
    • Use past studies, known alternatives, existing make/buy criteria.
    • Conduct studies:
      • Assess potential products and technologies.
      • Assess how well technical requirements are addressed.
      • Assess estimated costs, including support.
      • Assess safety criticality.
      • Identify risks (delivery, safety, development practices used by supplier, supplier track record, etc.).
      • Assess provider business stability, past performance, ability to meet maintenance requirements, etc.
      • Assess commercial off-the-shelf/government off-the-shelf/military off-the-shelf products for potential use. (See SWE-027.)
    • Identify in-house capabilities to meet the need:
      • Assess availability of existing products which could meet the need or be modified to meet the need.
      • Assess availability of qualified personnel for development or modification activities.
      • Assess estimated costs (time, personnel, materials, etc.), including support.
        • Use past projects as basis, where appropriate.
      • Identify risks.
    • Determine if solution will be custom made, an existing product, or a modified existing product.
  6. Identify any acquisition risks based on requirements and “make or buy” decisions.
  7. Create at least one government software cost estimate (SWE-015) for this work.
  8. Document analysis:
    • Expected classification of the software to be acquired.
    • Availability of in-house staff and funding resources.
    • Availability of the software product(s).
    • Projected licensing and support costs.
    • List of potential suppliers.
    • Security considerations.
    • Potential risks related to supplier’s viability and past performance.
  9. Document solution choice and basis for that choice:
    • Estimate of in-house versus acquisition costs (including OTS solutions and any associated costs for requirements not met by the OTS solution).
    • Comparison of cost estimates to available funding.
    • Risk assessment.
    • Assumptions, observations, rationale, determining factors.
    • Significant issues, impacts of each option.
    • If solution is in-house development/service, an acquisition is no longer required.
    • If solution is to acquire product/service, continue with this guidance as needed based on development under contract or purchase OTS solution.
    • Other planning decisions resulting in best overall value to NASA.
    • Description of chosen acquisition strategy.
  10. Identify

    <ac:macro ac:name="unmigrated-wiki-markup">
    <ac:plain-text-body><![CDATA[

    relevant stakeholders

    ]]></ac:plain-text-body>
    </ac:macro>

    based on requirements and “make or buy” decisions:
    • Those directly concerned with, or affected by, the acquisition decision. 
    • May include management, the project team, procurement, customers, end users, and suppliers.
  11. Ensure acquisition team includes organization from NASA (acquirer) with appropriate (see SWE-032) non-expired Capability Maturity Model Integration (CMMI®) rating as measured by a Software Engineering Institute (SEI) authorized or certified lead appraiser.*
  12. Report analysis and resulting decision to appropriate stakeholders.
  13. Document lessons learned for future acquisition activities.
  14. Develop acquisition schedule, including solicitation, supplier selection, supplier monitoring, and product acceptance and transition to operations, as appropriate.
  15. Develop acquisition plan using Center-specific template.

*Class A software acquisition guidance – When a project seeks to acquire a system that includes Class A software, the project's acquisition team is required to have support from personnel in an organization that has been rated at a Capability Maturity Model Integration for Development (CMMI®-DEV) Maturity Level 3 or higher or rated at CMMI®-DEV Capability Level 3 in at least the process areas of Supplier Agreement Management and Process and Product Quality Assurance. Evidence that a CMMI®-DEV Level 3 rated organization has participated in the acquisition activities could include direct support on the acquisition team and/or review and approval of the acquisition products by the CMMI®-DEV rated organization. The extent of the CMMI®-DEV Level 3 rated organization's support required for a Class A acquisition should be determined by the Center's Engineering Technical Authority responsible for the project. Identification of the appropriate personnel from an organization that has been rated at a CMMI®-DEV Level 3 or higher to support the project acquisition team is the responsibility of the designated Center Engineering Technical Authority and Center management.

Class B software acquisition guidance - In the case of the project's acquiring a system that includes Class B software, the project's acquisition team is required to have support from organizations that have been rated at CMMI®-DEV Level 2 or higher or rated at CMMI®-DEV Capability Level 2 in at least the process areas of Supplier Agreement Management and Process and Product Quality Assurance. Evidence that a CMMI®-DEV Level 2 rated organization has participated in the acquisition activities could include direct involvement in the development of supplier agreements or review and approval of these agreements. The support must also include review and approval of any software-related contract deliverables. The Center Engineering Technical Authority responsible for the project determines the extent of the CMMI®-DEV Level 2 rated organization's support required for a Class B acquisition. Identification of the appropriate personnel from an organization that has been rated at a CMMI®-DEV Level 2 or higher to support the project acquisition team is the responsibility of the designated Center Engineering Technical Authority and Center management.

Classes A and B general guidance - The Center Engineering Technical Authority has the responsibilities for ensuring that the appropriate and required NASA software engineering requirements are included in an acquisition. For those cases in which a Center or project desires a general exclusion from the NASA software engineering requirement(s) in this NPR or desires to generically apply specific alternate requirements that do not meet or exceed the requirements of this NPR, the requester shall submit a waiver for those exclusions or alternate requirements for approval by the NASA Headquarters' Chief Engineer with appropriate justification. 

  • No labels