bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

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

Compare with Current View Page History

« Previous Version 63 Next »


SWE-048 - Solicitation

1. Requirement

2.6.2.6 The project shall document in the solicitation the software processes, activities, and tasks to be performed by the supplier.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

Class D and not Safety Critical and Class G are 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?

   

   

   

   

   

   

   

    P(C)

   

   

   

    P(C)

   

Key:    A_SC = Class A Software, Safety Critical | A_NSC = Class A Software, Not Safety Critical | ... | - Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

2. Rationale

Suppliers (or providers) are accountable for what is stated in their contract and may perform only those tasks stated in that document. The precursor to the contract is the solicitation or request for proposals (RFP) which contains a Statement of Work (SOW). The SOW in the solicitation is the first description of the work for potential providers and needs to contain as much information as possible to ensure potential providers are prepared to perform and deliver what is required for a project.

Acquirers may better assess the capabilities of potential providers by including standards, tasks, activities, processes, requirements, etc. in the solicitation.  This will offer potential providers the opportunity to address these items in their responses.

Including information, such as standards, tasks, activities, processes, requirements, etc., in the solicitation is also useful to the provider community because it allows providers to gauge how well their existing or obtainable skills, resources, and capabilities match up to the required work.

3. Guidance

Typically, solicitations are prepared by the procurement or contracts department with input from project management and engineering.  When determining processes, activities, and tasks to include in the solicitation as items to be performed by the supplier (or provider), include the requirements from NPR 7150.2, but tailored for the project and to exclude Center and NASA Headquarters requirements (see Topic 7.4 - Flow Down of NPR Requirements to Contracts and to Other Centers in Multi-Center Projects). Consider the following, non-exhaustive list of key concepts for the solicitation:

  • Development standards to be followed by the provider.
  • Adherence to requirements for safety-critical software (see SWE-134, SWE-023, and NPR 7150.2, Appendix D).
  • Development life cycle to be followed by the provider, or indication that provider can choose life cycle.
  • Surveillance activities (and acquirer involvement) including monitoring activities, reviews, audits, decision points, meetings, etc. (see SWE-039).
  • Management and support activities (project management; schedule and schedule updates; configuration management of software products, documentation, and software development environment (hardware and software); non-conformance and change tracking; risk management; metrics collection; Independent Verification and Validation (IV&V) support and access; required records; traceability records; electronic records and code access; Verification and Validation (V&V), etc.).
  • Maintenance and support tasks, including updates, new versions, training to be included in life cycle and cost estimates.
  • Deliverables with delivery dates, review periods, and acceptance procedures for each.
  • Activities and responsibilities related to government and contractor proprietary, usage, ownership, warranty, data, and licensing rights, including transfer.
  • Tasks related to OTS (Off the Shelf) software requirements (identify which requirements are met by OTS software, provide OTS software documentation such as usage instructions, etc.) (see SWE-027)
  • Use of Open Source (see SWE-041)
  • Capability Maturity Model Integration (CMMI) ratings (see SWE-032) and associated rated process areas to be performed on the project for software Classes A, B, and C.

Be as complete as possible to ensure potential providers are aware of all tasks and activities for which they will be held responsible. 

Use checklists (e.g., the NASA PAL contains checklists for NPR 7150.2 requirements by class and safety criticality) and solicitations for similar projects to ensure that all required activities are included in the solicitation. Be sure to use example solicitations, SOWs (Statement of Work), and WBS (Work Breakdown Structure)s considered "best practices"; using problematic examples will only carry forward the problems exhibited or caused by those documents. 

The following is a list of useful practices when documenting tasks and activities in the solicitation:

  • Keep the task descriptions clear, concise, and in terms that providers will understand.
  • Avoid over-specifying (specifying every item to the smallest detail leaving no options).
  • Avoid under-specifying (providing insufficient or incomplete details).
  • Include a complete set of deliverables with descriptions and delivery format.
  • Include templates or Data Item Descriptions (DID) for documentation deliverables (see Book B guidance in this Handbook for NPR 7150.2, Chapter 5, Software Documentation Requirements, as applicable by software class).
  • Include time period for responses to review findings, including making changes.
  • Include Data Requirements Documents for deliverables, if appropriate.
  • Include a list of all mandatory NASA software development standards, documentation, and DIDs, as applicable
  • Clearly mark mandatory versus optional/recommended tasks, activities, standards, etc.

For additional considerations for a solicitation to acquire software, see Topic 7.3 - Acquisition Guidance in this Handbook. The SOW checklist and references in this topic may also provide additional guidance on project tasks to consider assigning to providers and including in the solicitation.

Additional guidance related to provider activities may be found in the following related requirements in this handbook:

SWE-027

Use of Commercial, Government, and Legacy Software (COTS, GOTS, MOTS, reused or Open Source software)

SWE-032

CMMI Levels for Class A, B, and C Software

SWE-037

Software Milestones

SWE-041

Open Source Software Notification

SWE-045

Project Participation in Audits

SWE-046

Software Schedule

SWE-047

Traceability Data

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.

5. Resources

  • (SWEREF-094) Software Acquisition Statement of Work Guideline, GRC-SW-7150.14, Revision C, NASA Glenn Research Center (GRC), April, 2011. This NASA-specific information and resource is available in Software Processes Across NASA (SPAN), accessible to NASA-users from the SPAN tab in this Handbook.

  • (SWEREF-341) Statement of Work (SOW) Review Procedure, LMS-CP-5523, Rev. B, Langley Research Center. This NASA-specific information and resource is available in Software Processes Across NASA (SPAN), accessible to NASA-users from the SPAN tab in this Handbook.


5.1 Tools

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

A 2001 Software Engineering Institute (SEI) report entitled Real-Time Systems: Engineering Lessons Learned includes the following lesson for SOWs, "Ensure that all critical functional and interoperability requirements are well specified in the contract (statement of work, Statement of Objectives)." The document includes some background and reason for this lesson.

  • No labels