bannerd

A. Introduction

B. Institutional Requirements

C. Project Software Requirements

D. Topics

E. Tools, References, and Terms

F. SPAN
(NASA Only)


SWE-016 - Software Schedule

1. Requirements

3.3.1 The project manager shall document and maintain a software schedule that satisfies the following conditions:

    1. Coordinates with the overall project schedule.
    2. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.
    3. Reflects the critical dependencies for software development activities.
    4. Identifies and accounts for dependencies with other projects and cross-program dependencies.

1.1 Notes

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

1.2 History

SWE-016 - Last used in rev NPR 7150.2D

RevSWE Statement
A

2.2.4 The project shall document and maintain a software schedule that satisfies the following conditions:

    1. Coordinates with the overall project schedule.
    2. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.
    3. Reflects the critical path for the software development activities.
Difference between A and B

Rev B adds item d. for adherence to NASA/SP-2010-3403

B

3.3.1 The project manager shall document and maintain a software schedule that satisfies the following conditions:

    1. Coordinates with the overall project schedule.
    2. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.
    3. eflects the critical path for the software development activities.
    4. Adhere to the guidance provided in NASA/SP-2010-3403, NASA Scheduling Management Handbook.
Difference between B and C

Removed reference to  NASA/SP-2010-3403; Changed critical path to critical dependency; Added identification and accountability for dependencies.

C

3.3.1 The project manager shall document and maintain a software schedule that satisfies the following conditions:

    1. Coordinates with the overall project schedule.
    2. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.
    3. Reflects the critical dependencies for software development activities.
    4. Identifies and accounts for dependencies with other projects and cross-program dependencies.

Difference between C and DNo change
D

3.3.1 The project manager shall document and maintain a software schedule that satisfies the following conditions:

    1. Coordinates with the overall project schedule.
    2. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.
    3. Reflects the critical dependencies for software development activities.
    4. Identifies and accounts for dependencies with other projects and cross-program dependencies.



1.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable


2. Rationale

To manage resource allocations and support the system development activities software projects need a detailed software schedule.

3. Guidance

The achievement of the goals and objectives of the project requires in-depth planning to develop and document and maintain an integrated set of work activities and tasks. This is normally accomplished through the use of a networked schedule. The schedule needs to include all the major activities for the project, along with its milestones and deliverables, to completely characterize all the work to be done on the project. This characterization, in turn, will allow the development of a complete listing and scheduling of needed personnel and related resources.

3.1 Schedule Includes Planned Activities

The software development team lead generates a software development schedule to include all activities described in the software development plan in response to the overall project/system schedule. The planned software activities need to include the detailed steps and tasks on a software schedule that meshes with the overall project schedule to assure timely and coordinated availability of the software work products for use in the overall system. Once the initial software schedule is developed and baselined, it needs to be maintained and updated to remain consistent with the overall schedule for the project.  This will eliminate overlapping demands and ensure the timely availability of project resources.

NASA Systems Engineering Handbook

"Scheduling is an essential component of planning and managing the activities of a project. The process of creating a network schedule provides a standard method for defining and communicating what needs to be done, how long it will take, and how each element of the project WBS might affect other elements. A complete network schedule may be used to calculate how long it will take to complete a project; which activities determine that duration (i.e., critical path activities); and how much spare time (i.e., float) exists for all the other activities of the project"  273

NASA Schedule Management Handbook,

“The purpose of schedule management is to provide the framework for time-phasing, resource planning, coordination, and communicating the necessary tasks within a work effort. The intent is to improve schedule management by providing recommended concepts, processes, and techniques used within the Agency and private industry.

The intended function of this handbook is two-fold: first, to provide guidance for meeting the scheduling requirements contained in NPR 7120.5, NASA Space Flight Program and Project Management Requirements, NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Requirements, NPR 7120.8, NASA Research and Technology Program and Project Management Requirements, and NPD 1000.5, Policy for NASA Acquisition. The second function is to describe the schedule management approach and the recommended best practices for carrying out this project control function.

... It is acknowledged that most, if not all, external organizations participating in NASA programs/projects will have their own internal schedule management documents. Issues that arise from conflicting schedule guidance will be resolved on a case by case basis as contracts and partnering relationships are established. It is also acknowledged and understood that all projects are not the same and may require different levels of schedule visibility, scrutiny, and control. Project type, value, and complexity are factors that typically dictate which schedule management practices should be employed.”

488

  • NPR 7120.5, NASA Space Flight Program and Project Management Requirements 082,
  • NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Requirements 264,
  • NPR 7120.8, NASA Research and Technology Program and Project Management Requirements 269, and
  • NPD 1000.5, Policy for NASA Acquisition 489.

3.2 Schedule Includes Milestones, Completion Dates of Deliverables 

The software development lead develops a preliminary software schedule that integrates with the overall project/system schedule, noting the dates for task completion/delivery, software peer reviews/inspections, deliverables, integration/testing, hardware tests, major project reviews, project milestones, purchases, training, documentation, and other pertinent scheduling data. It typically shows the relationships and dependencies of the software work products on hardware, operations, and training needs. The lead includes activities related to other key processes, such as acquisition, metrics, configuration management, and software assurance. The lead also refines the project's software schedule based on the cost estimate and resources obtained. The software schedule is developed and maintained following the guidance provided in NASA/SP-2010-3403, NASA Schedule Management Handbook  488 and is typically documented as part of the software management plan (see 5.08 - SDP-SMP - Software Development - Management Plan). For NASA Space Flight Projects, this Handbook provides a table of software life cycle products and their maturity milestone reviews [e.g., preliminary design review (PDR), critical design review (CDR)] in 7.08 - Maturity of Life Cycle Products at Milestone Reviews to assist in planning the software schedule. See also Topic 5.05 - Metrics - Software Metrics Report

A Gantt chart 192 is a useful tool for planning and scheduling projects. Program Evaluation and Review Technique charts (PERT) can be used to show dependencies of activities that are contained in the schedule. They can help determine critical paths, key events, and need dates. Tools such as Microsoft® Office Project, OmniGroup® Omniplan, or Oracle ® Primavera can be used to schedule and track software development activities.

The software schedule can be developed and maintained using the following process steps:

Develop the schedule:

  • Develop work breakdown structure (WBS) and overall network schedule.
  • Define the software milestone constraints, including start date, project reviews, hardware and operations flows and dependencies, and completion dates to support the top-level project schedule.
  • Review work requirements to be performed; enter task durations, resource names, and units.
  • Review/adjust work requirements to be performed as necessary (to ensure a reasonable schedule).
  • Include a margin or amount of slack time based on project length, team experience, or other relevant factors.
  • Review/adjust resource allocations and project durations with the project team and customer as required.
  • Schedule the duration (including beginning and ending dates) of various software development functions, such as requirements definition, design, coding, verification, and maintenance.
  • Schedule software-specific milestones, such as software deliveries and reviews.
  • The schedule needs dates and availability dates of critical dependency items.
  • Show the development activities associated with components of the Computer Software Configuration Items (CSCI).
  • Coordinate with disciplines and organizations that provide products/artifacts to software development, such as computer hardware, digital simulations, and dynamics algorithms.
  • Coordinate with disciplines and organizations that require products/artifacts from software development.
  • Establish the schedule baseline (project lead) with management approval.

Maintain the schedule:

  • Report the status of the development effort to project management through status meetings.
  • Report issues that impact the software development team's ability to adhere to the schedule to senior management and to project management as appropriate.
  • Monitor the remaining slack or margin in the project to help identify quickly if requirement changes or schedule modifications are required.
  • Resolve issues and/or revise the schedule. (Through the duration of the project, the software development team lead evaluates the impact of proposed project requirements changes and produces schedule updates that meet the approval of the project. If schedule changes are not possible, other means, such as changing or reducing requirements, can be investigated.)

3.3 Identify Critical Dependencies

The software schedule is an integral part of the overall project/system schedule and as such contributes to the critical path for the project.  The software lead must identify and understand the impact that the software development activities have on the overall integrated project schedule.  It is also important that the software leads to understanding the relationship between software development tasks and their interfaces with other project tasks. This will allow the software lead to assess changes to the project schedule that may affect software development as well as software changes that may affect the integrated project schedule. The software development team regularly evaluates the software schedule for apparent and hidden issues and risks. One means to perform these evaluations is to use the "critical path" methodology. "'Critical path'" is [characterized by determining] the sequence of dependent tasks that determines the longest duration of time needed to complete the project. These tasks drive the schedule and continually change, so they must be updated. The critical path may encompass only one task or a series of interrelated tasks." 273 The software lead identifies the critical path and the resources needed to complete the critical tasks along the path if the software development is to be completed on time and within its resources. As the development of the software work products progresses, the critical path changes as the critical tasks are completed or as other tasks are delayed. This evolving critical path with its identified tasks needs to be carefully monitored during the progression of the work. 273

3.4 Identify Other Project and Cross-Program Dependencies 

Critical path analysis constructs a model of the project that includes the following:

  • A list of all activities required to complete the project (typically categorized within a work breakdown structure).
  • The time (duration) that each activity will take to be completed.
  • The dependencies between the activities.

Using these values, a critical path analysis will calculate the longest path of planned activities to the end of the development activities, and the earliest and latest that each activity can start and finish without making the project longer. This process determines which activities are "critical" (i.e., on the longest path) and which have "total float" (i.e., can be delayed without making the time period longer). Any delay of an activity on the critical path directly impacts the planned project/system completion date (i.e. there is no float on the critical path). A software development activity can have several, parallel, near-critical paths. An additional parallel path through the graph with the total durations shorter than the critical path is called a sub-critical or non-critical path.

These results allow managers to prioritize activities for the effective management of work product completion, and to shorten the planned critical path of a task by pruning critical path activities, by "fast-tracking" (i.e., performing more activities in parallel), and/or by "crashing the critical path" (i.e., shortening the duration of critical path activities by adding resources).

See also, SWE-046 - Supplier Software Schedule

3.5 Additional Guidance

Additional guidance related to software project schedules may be found in the following related requirements in this Handbook:

Related Links

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. https://nen.nasa.gov/web/software/wiki  197

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

SPAN Links

4. Small Projects

Microsoft's Project software is frequently used to develop and track schedules.  This software is typically accessible for use on small projects.  The level of detail associated with a small project's schedule could be less than that for a larger project.  This saves small projects time in both the development and tracking of the schedule. Use a tool that is appropriate for the scale of your project. The development team may also use a Project Management Tool (like Microsoft® Project or Omniplan) to which it already has access. However, a small project of 2-3 people, or a project of less than 1 month, that may not already have access to an existing tool, may be better served by a Microsoft® Excel/Word or text-based schedule than by acquiring and being trained on using a project management tool.

5. Resources

5.1 References

Click here to view master references table.

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

  • One of the activities in the Orbital Space Plane (OSP) program required the review of a project schedule in a short time (9000 pages in 45 days). However, the lack of integration between NASA's schedule and the contractors' schedules led to a failure to foresee the consequences of accelerating the schedule. The overall finding recommends that the program should integrate both the NASA and contractor schedules and those schedules should be resource loaded. 445
  • If only high-level schedule risks are considered because of the lack of an integrated continuous risk management plan, longer-term risks ("Risks beyond a short time...") to the overall schedule may not be identified and mitigated.  See the Software Program Managers Network lesson learned schedule entry under "Continuous Risk Management." 446

7. Software Assurance

SWE-016 - Software Schedule
3.3.1 The project manager shall document and maintain a software schedule that satisfies the following conditions:
    1. Coordinates with the overall project schedule.
    2. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.
    3. Reflects the critical dependencies for software development activities.
    4. Identifies and accounts for dependencies with other projects and cross-program dependencies.

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. Assess that the software schedule satisfies the conditions in the requirement.

2. Develop a software assurance schedule, including software assurance products, audits, reporting, and reviews.

7.2 Software Assurance Products

  • Software Assurance Plan 
  • Software Assurance Plan Assessment
  • Software Engineering Plans Assessment 
  • A software assurance schedule including SA/Safety products and activities aligned with project activities (e.g. audits, reporting, and reviews)

Assessment results on software schedule, including any inconsistencies, issues, or risks.


Objective Evidence

  • Software schedule

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.

See also Topic 8.12 - Basics of Software Auditing. 

7.3 Metrics

  • Deviations of actual schedule progress vs. planned schedule progress above defined threshold
  • # of peer reviews performed vs. # of peer reviews planned
  • # of Peer Review Audits planned vs. # of Peer Review Audits performed
  •  # of Compliance Audits planned vs. # of Compliance Audits performed
  •  # of Open vs. Closed Audit Non-Conformances over time 
  • Trends of # of Non-Conformances from audits over time (Include counts from process and standards audits and work product audits.)
  • # of Non-Conformances per audit (including findings from process and compliance audits, process maturity)
  • # of process Non-Conformances (e.g., activities not performed) identified by SA vs. # accepted by the project
  • Trends of # Open vs. # Closed over time

See also Topic 8.18 - SA Suggested Metrics

7.4 Guidance

Step 1 - Assess that the software schedule satisfies the following conditions:

    1. Coordinates with the overall project schedule. - determine if the software schedule supports the project schedule milestones and provides reasonable margins and durations for the type of software development activities.
    2. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system. - determine if the software schedule supports the hardware availability, integration, and test milestones and provides reasonable margins and durations for the type of software development activities. Determine if the software schedule supports the operations milestones and provides reasonable margins and durations for the type of software development activities.
    3. Reflects the critical dependencies for software development activities - are the software engineering and software assurance products and milestones included on the schedule
    4. Identifies and accounts for dependencies with other projects and cross-program dependencies.

Step 2 - The software assurance schedule can be developed and maintained using the following process steps:

Develop the schedule:

  • Define the software assurance milestone constraints, including start date, project reviews, and completion dates to support the top-level project schedule.
  • Review work requirements to be performed; enter task durations, resource names, and units.
  • Review/adjust work requirements to be performed as necessary (to ensure a reasonable schedule).
  • Include a margin or amount of slack time based on project length, team experience, or other relevant factors.
  • Review/adjust resource allocations and project durations with the project team and customer as required.
  • Schedule the duration (including beginning and ending dates) of various software assurance assessment functions and audits.
  • Schedule milestones, such as software assurance audits, product deliveries, assessments, and review support.
  • Show the development activities.
  • Coordinate with disciplines and organizations that provide products/artifacts to software assurance.
  • Coordinate with disciplines and organizations that require products/artifacts from software assurance and software safety.
  • Establish the schedule baseline (project lead) with management approval.

Examples of items on a Software Assurance schedule could include:

  • Software Assurance plan,
  • Software Assurance audit,
  • Software Assurance status reports,
  • Software assurance and software safety requirements mapping table for the Software Assurance and Software Safety standard requirements, the cost estimate for the project’s Software Assurance support, Software Assurance and software safety reviews and software assurance review support,
  • IV&V planning and risk assessment, if required.
  • The IV&V Execution Plan, if required.
  • System hazard analysis assessment activities,
  • Software Safety Analysis,
  • Software Assurance independent static code analysis for cybersecurity vulnerabilities and weaknesses,
  • Software Assurance independent static code analysis, on the source code, showing that the source code follows the defined secure coding practices,
  • Software Assurance analysis performed on the detailed software requirements,
  • Software assurance design analysis, SA peer reviews,
  • Software Assurance metric data, reporting, and analysis activities,
  • Software Assurance status reviews.

See also Topic 8.51 - Software Assurance Plan,

Maintain the schedule:

  • Report the status of the development effort to project management through status meetings.
  • Report issues that impact the software assurance team's ability to adhere to the schedule to senior management and to project management as appropriate.
  • Monitor the remaining slack or margin in the project to help identify quickly if requirement changes or schedule modifications are required.
  • Resolve issues and/or revise the schedule.
  • Resolve any resource issues with the project.

The software schedule is an integral part of the overall project/system schedule and as such contributes to the critical path for the project.  The software assurance must identify and understand the impact that the software development activities have on the overall integrated project schedule.  It is also important that software assurance understand the relationship between software development tasks and their interfaces with other project tasks. This will allow the software assurance to assess changes to the project schedule that may affect software development as well as software changes that may affect the integrated project schedule. The software assurance team regularly evaluates the software schedule for apparent and hidden issues and risks.

Schedule path analysis constructs a model of the project that includes the following:

  • A list of all activities required to complete the project (typically categorized within a work breakdown structure).
  • The time (duration) that each activity will take to be completed.
  • The dependencies between the activities.

7.5 Additional Guidance

Additional guidance related to software project schedules may be found in the following related requirements in this Handbook:

Related Links
  • No labels
Page Editor: Tim Crumbley
NASA Official: Tim Crumbley
Accessibility
NASA Software Engineering Handbook - A service of the NASA Office of the Chief Engineer
NASA Privacy Statement
______________________________________________________________________________