Overview
The software project schedule is iteratively developed to coincide with establishing the work breakdown structure (WBS) and preparing the project cost estimate. A summary top-level schedule is typically a one-page chart showing the planned start and end dates of each major computer software configuration item (CSCI) over the project’s duration. The schedule must fit the project’s time constraints, including any firm deadlines. A more detailed-level schedule shows the planned start and end dates of the WBS elements making up the CSCIs, as well as the acquisition of necessary hardware and software tools. The detailed schedule identifies specific team members and factors in resource availability and time constraints. This detailed schedule must fit within the top-level schedule, and make sure that task durations are accurate, and dependencies are identified to establish the critical path in project execution. In developing a viable schedule for the software components, it is important to understand any scheduling constraints imposed by major system milestones. Likewise, it is important to be aware of any changes in the project’s scope, and to assess the impact of such changes on project schedules.
Roles and Responsibilities
The project software manager and software engineering manager (if assigned) develops the software schedule.
The project manager reviews the top-level schedule.
The software engineering process group members (SEPG) may be consulted to estimate the duration of low-level activities.
Controls
Software development process selected for the project (see activity 1.1.1.3 Define Software Development Process) which identifies the life cycle approach and any intermediate builds.
The Project Plan containing the project schedule and identifying significant project milestones.
Inputs
Cost estimates which may provide the expected cost and manhours by life cycle phase (this is tool dependent) (see activity 1.1.1.1.4 Perform Cost Estimating).
Software Configuration Management Plan (SCMP) and Software Test Plan (STP) (see Appendix E for Data Item Descriptions (DIDs)), which provide information on resources and milestones that must be in the schedule (e.g., Functional Configuration Audit (FCA), Physical Configuration Audit (PCA), acquiring software configuration management (SCM) tools, test tools) (see activities 1.1.2 Plan Software Configuration Management and 1.1.3 Plan Software Testing).
The WBS which identifies the products to be developed (see activity 1.1.1.1.2 Develop Work Breakdown Structure).
Software project organization and resources which identify the personnel and software project resources (i.e., software engineering environments) that must be acquired (see activity 1.1.1.2 Identify Software Project Organization And Resources).
Procedures
1) The project software manager reviews the project schedule (as documented in the Project Plan) focusing on major project milestones and dependencies which would impact the software schedule.
2) Based on the identified software project life cycle, the project software manager creates the top-level schedule. The top-level schedule should show start and completion dates for all computer software configuration items (CSCI) identified in the WBS, as well as the major project milestones. Any dependencies between the CSCIs should be identified, and the project software manager should determine if the project milestones and deadlines can be met. The project software manager reviews this top-level software schedule with the project manager. If it is determined that the project schedule cannot be met, the project software manager should work with the project manager to determine the alternatives.
3) The project software manager, together with the software engineering manager, estimates the durations of all lower-level activities (e.g., preliminary design, detailed design) associating the WBS elements with these activities so that all dependencies between WBS elements are identified (e.g., the required acquisition of development tools is synchronized with the activities requiring those tools). Depending on the scheduling tool, an activity network may be generated showing the relationships and dependencies among the activities and identifying those on the critical path that impose the greatest time restrictions. SEPG members may be consulted, as well as some cost models (e.g., SEER), to determine the amount of time required to perform the lower-level activities. During this exercise, the project software manager should attempt to identify any activities which can be done in parallel, thus reducing the overall software project duration (e.g., software test plans may be started as soon as the software requirements are identified). The critical path for the project then can be generated. When the software project’s organization and personnel are selected, the project software manager should verify that the proper personnel will be available for the scheduled activities.
Any identified schedule problems in meeting the project schedule should be identified to the project manager.
4) The software project schedule and activity network are placed in the Schedules and Activity Network section of the SDP.
Outputs
The software project schedule (both top level and detailed) with the associated activity network(s). The schedule normally is kept in a scheduling tool; however, copies are placed in the Schedules and Activity Network section of the Software Development Plan (SDP) (see Appendix E).