"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" .
“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 NASA Scheduling Management Handbook provides “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 [NASA Scheduling Management Handbook also describes] the schedule management approach and [associated] recommended best practices ...” 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.”
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 and is typically documented as part of the software management plan (see SDP-SMP). 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 Topic 7.8 - Maturity of Life-Cycle Products at Milestone Reviews to assist in planning the software schedule.
A Gantt chart 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 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.
- 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.)
The software schedule is an integral part of the overall project/system schedule and as such contributes to the critical path for the project. It is important that the software lead identify and understand the impact that the software development activities have on the overall integrated project schedule. It is also important that the software lead understand the relationship between the 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." 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.
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 durations of critical path activities by adding resources).
NASA-specific software schedule information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.
Additional guidance related to software project schedules may be found in the following related requirements in this Handbook: