2.5.4 For new contracts, the project shall establish a procedure for software supplier selection, including proposal evaluation criteria. NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement. Classes C through E and Safety Critical are labeled, "SO if D-E." This means that for Classes D through E, this requirement applies only to the safety-critical aspects of the software. Class H is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement. Class A_SC A_NSC B_SC B_NSC C_SC C_NSC D_SC D_NSC E_SC E_NSC F G H Applicable? X X X P(C) Key: A_SC = Class A Software, Safety-Critical | A_NSC = Class A Software, Not Safety-Critical | ... | - Applicable | - Not Applicable When choosing a supplier to create software, it is important to use a consistent evaluation process for all potential suppliers. An established evaluation process includes criteria by which all proposals are weighed allowing the results to be compared equally and as objectively as possible. A process with pre-set criteria helps ensure that each proposal is evaluated and the final choice made based on the most important features and capabilities required for project success. The base set of suppliers may come from a variety of sources, including market analyses of software suppliers, pre-existing supplier lists, or simply the set of respondents to a request for proposals (RFP). "In some organizations, acquirers may solicit proposals from a limited number of suppliers to reduce their cost and efforts for the solicitation. Acquirers should, however, ensure that they include suppliers who are capable of meeting the requirements and that a sufficient number of suppliers are included to provide a competitive environment. This competition enhances the leverage of the acquirer in achieving its objectives (e.g., providing different approaches to meeting requirements). In some cases, the organization pre-qualifies preferred suppliers from which an acquirer can choose provided the preferred suppliers meet the specific needs of the project. Choosing from preferred suppliers can greatly reduce the effort and time required for solicitation. "Depending on applicable regulations and project characteristics, the acquirer can determine to pursue a sole-source acquisition rather than a competitive bid. Acquirers should document the rationale for determining potential suppliers, particularly in the case of sole-source selection." 328 "An established procedure and set of evaluation criteria is used to select the most qualified supplier for a new contract. The selection procedure includes the evaluation criteria as well as the method for evaluating proposals. Supplier selection decisions "must be carefully managed in accordance with regulations governing the fairness of the selection process." 273 Supplier selection procedure The selection procedure may be documented in a source selection plan that contains the following suggested sections: Additionally, the selection procedure normally includes a source selection authority (SSA) as appropriate for the size or priority of the project 002. The SSA will make the final supplier selection using input from a selection/evaluation team. Members of the selection team are typically chosen and confirmed well before proposals arrive for evaluation. Members typically include technical experts, a contracting specialist, and software assurance. Having software assurance on the team is "essential not only for establishing appropriate Software Assurance requirements, but also in evaluating potential contractors and ensuring that secure software is delivered." 301 The results of the selection procedure, including notes regarding advantages, disadvantages, and scores for each potential supplier, need to be documented and maintained. If the selection process includes a period for questions or a period for negotiations with potential suppliers before a selection is made, those processes and any bounding regulatory restrictions that apply should be included in the process documentation. 328 The NASA Systems Engineering Handbook 273 includes the following proposal evaluation advice: Proposal evaluation criteria Evaluation criteria are used to rate or score proposals received in response to a solicitation. Evaluation criteria for selecting a supplier must appear in the solicitation. Consider the following possible criteria: Additional evaluation considerations may be found in the supplier evaluation checklist in IEEE STD 1062-1998, IEEE Recommended Practice for Software Acquisition, 213 which contains questions for consideration specific to: Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to supplier selection. See Topic 7.3 - Acquisition Guidance in this Handbook for additional guidance and a broader discussion on software acquisition. The references in this topic may also provide additional guidance on creating a procedure for supplier selection. If supplier selection includes COTS/GOTS/MOTS products, see SWE-027 for guidance relevant to this type of software and software suppliers. If supplier selection includes Open Source Software products, see SWE-041 for guidance relevant to this type of software and software suppliers. Additional guidance related to acquisition and supplier selection may be found in the following related requirement in this Handbook: Use of Commercial, Government, and Legacy Software (COTS, GOTS, MOTS, etc.) CMMI Levels for Class A, B, and C Software Acquisition vs. Development Assessment Acquisition Planning Open Source Software Notification No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph. Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN). NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN. The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider. A documented lesson from the NASA Lessons Learned database notes the following: Inheritance Review of the Mars Phoenix Flight System. Lessons Learned Entry 1807: "Despite the unusually large percentage of the Phoenix design and hardware that was inherited from previous Mars spaceflight projects, the format used for Phoenix project system and subsystem Inheritance Reviews (IRs) proved adequate to mitigate the risk within technical and programmatic constraints. A mission assurance checklist provided acceptance criteria to validate the flight worthiness of each subsystem. Consider using the Phoenix Inheritance Review format as a model for future missions that feature substantial inheritance. Plan carefully for the collection, analysis, and eventual archiving of records documenting the system and subsystem pedigree."
See edit history of this section
Post feedback on this section
1. Requirements
1.1 Notes
1.2 Applicability Across Classes
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures2. Rationale
3. Guidance
4. Small Projects
5. Resources
5.1 Tools
6. Lessons Learned
SWE-035 - Supplier Selection
Web Resources
View this section on the websiteUnknown macro: {page-info}