This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C
3.12.7 The project manager shall document software acquisition planning decisions.
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
1.2 Applicability Across Classes
Classes F and G are labeled as "X (not OTS)" which means that the project is required to meet this requirement for all software that is not considered off-the-shelf.
Class A B C CSC D DSC E F G H Applicable?
Key: - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.
There are many reasons to document acquisition planning decisions, not the least of which is to have a record of those decisions for future reference.
Documentation of software acquisition planning decisions is essential to project management and is important when changes to initial project formulation assumptions require renegotiation of acquisition activities. Records of decisions also serve as confirmations or reminders to project participants should any misunderstandings or conflicts arise as the project progresses. Lengthy projects with multiple development groups, including subcontractors, with the potential for changing personnel make it important to document decisions so that everyone continues to work toward the same goals using the same guidelines.
When capturing acquisition planning decisions, be sure to include any related analysis that led to those decisions as that information could be important for lessons learned and future acquisition activities. The analysis typically includes the alternatives considered, the selection or evaluation criteria used to arrive at the decision, and any process used to arrive at the decision. If the team used a documented process to arrive at the decision, a reference to the process document including its location in a Center or NASA Process Asset Library (PAL), if applicable, is captured as background for the decision. Additionally, it may be useful to include the name or role of the person making or approving the acquisition planning decision for the project. All of this information will be useful to those who need to make similar decisions in the future.
When determining the information to capture, consider the following, as appropriate for the project:
- Decisions and related analysis and/or justification regarding project scope.
- Make vs. buy analysis and resulting decisions, see SWE-033.
- Information needs for monitoring the management and technical performance on the contract.
- Division of responsibilities between government and contractor.
- Selection process, including evaluation criteria, and award decision for acquired software development services, see SWE-035.
- Negotiated contract decisions and justification, including, but not limited to, negotiated decisions related to:
- Requirements included or excluded from the contract, including tailoring of requirements.
- Processes, activities, and tasks included or excluded from the contract or Statement of Work (SOW), see SWE-036.
- Standards to be followed.
- Cost and budget.
- Risk and risk management.
- Schedule, including milestones and reviews, see SWE-037.
- Acceptance criteria for deliverables, including software, see SWE-034.
- Support from developer such as maintenance, operations, and retirement support.
- Stakeholder commitments.
Capture this information as accurately as possible in the project acquisition plan or in another project planning document.
The following Center guidance may provide insights into acquisition planning decisions that are documented in the acquisition plan:
- Process Monitoring and Control (PMC).
See the Topic 7.3 - Acquisition Guidance in this Handbook for additional guidance on acquisition activities and related decisions.
When considering which decisions are important enough to document:
- Consult experienced project management personnel for advice.
- Consider the impact of the decision on the project; the higher the degree of impact on cost, schedule, safety, technical outcome, software performance, etc. the more important it is to document the decision.
- Be sure to capture controversial decisions and "command" decisions.
4. Small Projects
If an acquisition plan does not exist for the project, another project planning document, such as the Project Plan or Software Development Plan, may be used to document acquisition planning decisions.
Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.
No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.
6. Lessons Learned
No Lessons Learned have currently been identified for this requirement.