Software Engineering-Scheduling of Software

Scheduling of a software project does not differ greatly from scheduling of any multitask engineering effort. Therefore, generalized project scheduling tools and techniques can be applied with little modification to software projects.

Program evaluation and review technique (PERT) and critical path method (CPM)  are two project scheduling methods that can be applied to software development. Both techniques are driven by information already developed in earlier project planning activities:
• Estimates of effort
• A decomposition of the product function
• The selection of the appropriate process model and task set
• Decomposition of tasks

Interdependencies among tasks may be defined using a task network. Tasks, sometimes called the project work breakdown structure (WBS), are defined for the product as a whole or for individual functions.

Both PERT and CPM provide quantitative tools that allow the software planner to
(1) determine the critical path—the chain of tasks that determines the duration of the project;

(2) establish “most likely” time estimates for individual tasks by applying statistical models; and (3) calculate “boundary times” that define a time "window" for a particular task.

Boundary time calculations can be very useful in software project scheduling. Slippage in the design of one function, for example, can retard further development of other functions. Riggs  describes important boundary times that may be discerned from a PERT or CPM network: 

(1) the earliest time that a task can begin when all preceding tasks are completed in the shortest possible time,

(2) the latest time for task initiation before the minimum project completion time is delayed, 

(3) the earliest finish—the sum of the earliest start and the task duration, 

(4) the latest finish— the latest start time added to task duration, and 

(5) the total float—the amount of surplus time or leeway allowed in scheduling tasks so that the network critical path is maintained on schedule. 

Boundary time calculations lead to a determination of critical path and provide the manager with a quantitative method for evaluating progress as tasks are completed.

Both PERT and CPM have been implemented in a wide variety of automated tools that are available for the personal computer . Such tools are easy to use and make the scheduling methods described previously available to every software project manager.

Timeline Charts

When creating a software project schedule, the planner begins with a set of tasks (the work breakdown structure). If automated tools are used, the work breakdown is input as a task network or task outline. Effort, duration, and start date are then input for each task. In addition, tasks may be assigned to specific individuals.

As a consequence of this input, a timeline chart, also called a Gantt chart, is generated. A timeline chart can be developed for the entire project. Alternatively, separate charts can be developed for each project function or for each individual working on the project.

Timeline chart depicts a part of a software project schedule that emphasizes the concept scoping task  for a new word-processing (WP) software product. All project tasks (for concept scoping) are listed in the left-hand column. The horizontal bars indicate the duration of each task. When multiple bars occur at the same time on the calendar, task concurrency is implied. The diamonds indicate milestones.

Once the information necessary for the generation of a timeline chart has been input, the majority of software project scheduling tools produce project tables—a tabular listing of all project tasks, their planned and actual start- and end-dates, and a variety of related information  Used in conjunction with the timeline chart, project tables enable the project manager to track progress.

Tracking the Schedule

The project schedule provides a road map for a software project manager. If it has been properly developed, the project schedule defines the tasks and milestones that must be tracked and controlled as the project proceeds. Tracking can be accomplished in a number of different ways:

• Conducting periodic project status meetings in which each team member reports progress and problems.
• Evaluating the results of all reviews conducted throughout the software engineering process.
• Determining whether formal project milestones  have been accomplished by the scheduled date.
• Comparing actual start-date to planned start-date for each project task 

• Meeting informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon.
• Using earned value analysis  to assess progress quantitatively.

In reality, all of these tracking techniques are used by experienced project managers. Control is employed by a software project manager to administer project resources, cope with problems, and direct project staff. If things are going well (i.e., the project is on schedule and within budget, reviews indicate that real progress is being made and milestones are being reached), control is light. But when problems occur, the project manager must exercise control to reconcile them as quickly as possible. After a problem has been diagnosed, additional resources may be focused on the problem area: staff may be redeployed or the project schedule can be redefined.

When faced with severe deadline pressure, experienced project managers sometimes use a project scheduling and control technique called time-boxing . The time-boxing strategy recognizes that the complete product may not be deliverable by the predefined deadline. Therefore, an incremental software paradigm is chosen and a schedule is derived for each incremental delivery.
The tasks associated with each increment are then time-boxed. This means that the schedule for each task is adjusted by working backward from the delivery date for the increment. A “box” is put around each task. When a task hits the boundary of its time box (plus or minus 10 percent), work stops and the next task begins.

The initial reaction to the time-boxing approach is often negative: “If the work isn’t finished, how can we proceed?” The answer lies in the way work is accomplished. By the time the time-box boundary is encountered, it is likely that 90 percent of the task has been completed.11 The remaining 10 percent, although important, can
(1) be delayed until the next increment or 

(2) be completed later if required.

 Ratherth an becoming “stuck” on a task, the project proceeds toward the delivery date.