When assessing solutions for software acquisition versus development, there are five possible options:
- Acquire an off-the-shelf software product that satisfies the requirement.
- Develop the software product or obtain the software service internally.
- Develop the software product or obtain the software service through contract.
- Enhance an existing software product or service.
- Reuse an existing software product or service.
Each option has its own benefits, costs, and risks which should be identified through trade studies (for off-the-shelf products), internal assessments (for existing products), and cost-benefit analyses. Checklists of questions to ask when assessing acquisition versus development can be found in SWE-027 - Use of Commercial, Government, and Legacy Software in this handbook.
Risks are considered in software make/buy and acquisition decisions. The project needs to ensure that software products used in the design or support of human space flight components or systems include a level of rigor in risk mitigation as a software management requirement, regardless of software classification. The level of documentation needed for risk identification and tracking is defined by the Center processes.
The team should assess existing software products, whether off-the-shelf or in-house, to identify how well they meet the need of the current project and whether they are suitable for the intended environment. The following information should be weighed against the defined need, architecture, environment, requirements, safety classification, budget, etc. of the current project:
- Test results.
- Performance record.
- Safety record.
- Licensing, maintenance, integration, and support costs.
- Any other relevant information.
The project responsible for procuring off-the-shelf software is responsible for documenting, prior to procurement, a plan for verifying and validating the off-the-shelf software to the same level of confidence that would be needed for an equivalent class of software if obtained through a "development" process. For more detail, see SWE-027 .
For development, whether internal or external, consider the following information:
- Personnel skill sets, experience, availability.
- Cost associated with training, tools, post-development maintenance and support.
- Company reputation, track record, history, etc. (for contracted development).
- Overall life-cycle cost, including cost of integration with existing software components.
- Intellectual property rights.
- Cost and availability of workforce should follow-on work be required.
- Insight into development processes.
- Schedule associated with procurement (sole source, competitive, task order, etc.) for procured software or a contracted development.
- Life-cycle supportability risks.
- Complexity of effort and extent of modifications required.
Identify risks associated with each assessed option, including:
- Technical risks.
- Supplier risks, including track record and support risks.
- Cost and schedule risks.
The team should document the results of the analysis as well as the raw data that was collected and evaluated to arrive at the final solution.
Involve the right stakeholders in the assessment process to benefit from their experience and ensure all key information is considered. Consider the following, as applicable:
- Technical personnel.
- End users.
- Technical Authority.
See topic 7.3 - Acquisition Guidance in this Handbook for additional guidance on this subject. The references in this topic may also provide additional guidance on assessing acquisition versus development options.
Additionally, Center procedures addressing decision analysis and resolution may be helpful in planning and carrying out the assessment and selection process.
NASA-specific acquisition process information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.