SWE-046 - Supplier Software Schedule

1. Requirements

3.3.3 The project manager shall require the software developer(s) to provide a software schedule for the project’s review, and schedule updates as requested.

1.1 Notes

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

1.2 History

SWE-046 - Last used in rev NPR 7150.2D

RevSWE Statement
A The project shall require the software supplier(s) to provide a software schedule for the project's review and schedule updates as requested.

Difference between A and B

No change


3.13.3 The project manager  shall require the software supplier(s) to provide a software schedule for the project's review and schedule updates as requested.

Difference between B and C

Changed "software supplier(s)" TO "software developer(s)"


3.3.3 The project manager shall require the software developer(s) to provide a software schedule for the project's review, and schedule updates as requested.

Difference between C and DNo change

3.3.3 The project manager shall require the software developer(s) to provide a software schedule for the project’s review, and schedule updates as requested.

1.3 Applicability Across Classes















Key:    - Applicable | - Not Applicable

2. Rationale

Software supplier scheduling activities must be monitored to assure the software work products that are required by a project are produced when they are needed by the project. NASA's insight into a supplier's development schedule provides a view of the software developer's activities and plans. The supplier's schedule allows the software team to determine the expected state of development of the software product. It then serves as a benchmark for measuring supplier accomplishment during regular reviews or formal design reviews. 

The purpose of this requirement and schedule management is to provide the framework for time-phasing, resource planning, coordination, and communicating the necessary tasks within a work effort. Sound schedule management requires the establishment, utilization, and control of a baseline master schedule and its derivative schedules (e.g., software schedules). An Integrated Master Schedule (IMS) provides the framework for time phasing and coordinating all project efforts into a master plan to ensure that objectives are accomplished within project or program commitments.

Schedule management encompasses the development, maintenance, control, and archival of the project schedules. The software schedule constitutes the basis for time phasing and coordinating all program/project software efforts to ensure that objectives are accomplished within approved commitments. Integrated schedules are crucial for all levels of management oversight within NASA and its contractor community. Software schedules contain the necessary tasks and milestones that reflect the total integrated plans for each software component within the program. While it is true that all software work scope must be included within a program IMS, the levels of detail may vary to accommodate the specific management needs established at the program level. Software schedule management entails the creation of a software schedule that contains integrated tasks and milestones for both contractor effort and effort being worked by in-house NASA government personnel.

Regardless of the type of project being implemented, the software schedule must contain data addressing the total scope of work at a consistent level of detail to allow for discrete progress measurement, management visibility, and critical path identification and control. This approach will allow Program and Project Managers greater visibility and capability to adequately plan the necessary resources, and to ensure an adequate budget will be available to accomplish the planned work.

3. Guidance

3.1 Software Schedule

Scheduling begins with project-level schedule objectives for delivering the products described in the upper levels of the Work Breakdown Structure (WBS) and evolves down to the software development level. See also Topic 7.05 - Work Breakdown Structures That Include Software.  The supplier includes software version descriptions and functionality of any deliverable software work products contained in the schedule of deliveries in the 5.16 - VDD - Version Description Document and the 5.05 - Metrics - Software Metrics Report. The project team, through the contract Statement of Work (SOW) (see 7.03 - Acquisition Guidance), must require the delivery of a software work product development schedule from the software supplier. Schedule content provided by the supplier to NASA includes networked activities evolved down to a level sufficient for the project team to obtain the necessary insight (see SWE-039 - Software Supplier Insight) into the state of the supplier's activities.

Networked schedule data consist of: 273

  • Activities and associated tasks.
  • Dependencies among activities (e.g., where an activity depends upon another activity for a receivable).
  • Products or milestones that occur as a result of one or more activities.
  • Duration of each activity.

The technical requirements need to be sufficiently detailed to assure that firm schedule estimates can be established. The schedule needs to show the major development activities throughout the life cycle, the milestones, and a critical path. See the SWE-016 - Software Schedule Software Schedule for in-depth information on the general preparation of software development schedules.

3.2 Linkages Across Schedules

To be effective, the software supplier schedule needs to have linkage to the project schedules, if the two are different. The suppler schedule can be analyzed for risk issues related to the schedule (long lead hardware needs, critical path, or lack of schedule slack). Good scheduling systems provide capabilities to show resource requirements over time and to make adjustments so that the schedule is feasible concerning resource constraints over time. The schedule can be resource loaded, thus enabling close tracking of technical parameters, milestones, and budgets to ensure that the team recognizes undesirable trends (such as unexpected growth in lines of code or increase in its cost) early enough to take corrective action.

3.3 Schedule Baseline

Once the supplier establishes firm software schedule estimates, the schedule can be baselined and controlled in the project's configuration management system. The project team needs to review these baselined schedules to ensure they are consistent with the overall project schedule.

3.4 Managing Schedule Variance

Managing schedule variance is one of the key responsibilities of the software development team in dealing with software suppliers. The difference between the budgeted cost of work performed and the budgeted cost of work scheduled is called the schedule variance at a time "t".  A negative value indicates that the work is behind schedule. 273 Schedule management tools can be employed by the project team to assist in its evaluation of the software supplier schedules. Whenever the software development planning experiences major changes from a baseline, an update to the schedule can be requested from the software supplied by the project to allow additional and appropriate insight into the activities to be developed and scheduled.

Regular schedule submissions and periodic updates are typically scheduled as part of the software development SOW. Because NASA projects and their software development activities experience numerous changes in requirements, scope, and funding, and ability to request updates whenever needed is typically included in the contract clauses. 

3.5 Additional Guidance

Additional guidance may be found in the following related requirements in this Handbook:

3.6 Center Process Asset Libraries

SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only.  197

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

This requirement applies to all projects regardless of size. Smaller projects may get by with fewer levels of detail in the schedule for the life cycle.

5. Resources

5.1 References

5.2 Tools

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.

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

SWE-046 - Supplier Software Schedule
3.3.3 The project manager shall require the software developer(s) to provide a software schedule for the project’s review, and schedule updates as requested.

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. Confirm the project's schedules, including the software assurance’s/software safety’s schedules, are updated.

7.2 Software Assurance Products

  • Schedule of Software Assurance activities 

    Objective Evidence

    • Software schedule(s)

    Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

    • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
    • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
    • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
    • Signatures on SA reviewed or witnessed products or activities, or
    • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
      • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
      • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
    • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

  • Deviations of actual schedule progress vs. planned scheduled progress above defined thresholds.

See also Topic 8.18 - SA Suggested Metrics

7.4 Guidance

See guidance listed in SWE-016 - Software Schedule and SWE-018 - Software Activities Review.

7.5 Additional Guidance

Additional guidance may be found in the following related requirements in this Handbook:

  • No labels