PROJECT SCHEDULING

Software project scheduling involves the allocation of resources to a project in a timely manner. As remarked earlier in this chapter, it is extremely inefficient to have a project that will take five years to complete and will need one thousand people at its peak and have all one thousand people on the payroll from the first day forward, when only twenty people might be needed for the first year.

The alternative is equally bad, however. If a project is severely understaffed at any criti- cal time, it is likely to be completed much later than desired, if at all. Adding extra people late in the process usually does not help, because the more experienced project personnel

TABLE 2.4 Coefficients for the Basic COCOMO Model

Software Project Type ab bb cb db

Small project, with an experienced team and flexible requirements

(commonly called a basic or “organic” system) 2.4 1.05 2.5 0.38 A system with hard real-time requirements and strict interoperability

required (commonly called an “embedded” system) 3.6 1.2 2.5 0.32 A mixture of the other two types of projects (commonly called an

“intermediate” level system) 3.0 1.12 2.5 0.35

Source: Boehm, B., Software Engineering Economics, Prentice Hall, Englewood Cliffs, NJ, 1981.

Line fit plot 30,000 25,000 20,000 Y 15,000 10,000 5,000 0 1 2 3 4 5 6 7 Predicted Y Y Observation

FIGURE 2.3 An attempt to fit a smooth curve to the data in the scatter diagram of Figure 2.2 using a COCOMO model approach.

are forced to spend much of their time bringing up the levels of understanding of the new people. In addition, having more people always means more meetings to coordinate, as we saw in Chapter 1.

The efficiency of the system’s software development is guided by its expected cost. A software economist will often have considerable experience with the pattern of staffing needed for projects of this size. He or she will often expect that the number of people employed on a software project will follow a relationship that might look something like that of Figure 2.4. The different line segments in the graph indicate different life cycle activities, each of which might require different numbers of people. Here the horizontal axis represents time and the vertical axis represents the number of personnel associated with the project between milestones.

The numbers at the beginning of the project represent the requirements team. The proj- ect size then increases to its maximum during the coding phase, which is intensive, but

TABLE 2.5 “Test Driver Attributes” for the Intermediate COCOMO Model

Test Driver Attribute Weight

Product Attributes

Reliability requirements Size of application’s database Software complexity

Hardware Attributes

Run-time performance constraints Memory limitations

Other processes competing for virtual memory

Personnel Attributes

Analyst experience

Software engineer experience Application domain experience Virtual machine experience Programming language experience

Project Attributes

Use of software tools

Use of software engineering methods Required development schedule Total

20 10 0

6 12 18 28 34 50

limited in time. The number of personnel will decrease as the testing and integration phase comes to an end. The last number represents the people needed for maintenance of the software. If the system has a long operational life, then it is easy to see that the cost of the maintenance phase will be the largest cost in the system, as we stated before.

Several techniques are often used for project scheduling. Two of the most common are: • Milestone charts

• Critical path methods

A simple example of a milestone chart was previously shown in Figure 1.4. (Other exam- ples of milestone charts were given in Figure 1.6 and Figure 1.8 for the rapid prototyping and spiral models, respectively. See Chapter 1.) A slightly more elaborate one with mile- stones for two different releases of the same system displayed is illustrated in Figure 2.5.

Note the multiple releases of the software. In organizations, such charts will include both the projected and actual dates of the individual milestones. Note also that reviews must be held for each milestone that is a deliverable product.

A less common method of planning and representing schedules is to use so-called “criti- cal path methods.” Critical path methods are based on the assessment that certain events are critical in the sense that they fundamentally affect several other decisions. Once these critical decisions have been determined, any events not affected by the critical ones can be scheduled at any time. For example, an ICD that describes precisely the interfaces between component subsystems must be produced and reviewed before a major effort in subsystem design and implementation begins. (We will describe ICDs in Chapter 4 when we study detailed design.) Requirements Design Code Integration Test Time Release Release

FIGURE 2.5 A typical milestone chart for a software project with multiple releases, following the classical waterfall software development process.

You should note how object-oriented design is consistent with the determination of crit- ical paths in software development. If we can describe the methods of an object in terms of an abstract class, then we know the class interface, and hence anyone developing a class that will interact with this class has enough information to develop code. That is, if we develop a class with complete descriptions of the number and type of arguments to meth- ods of the class, as well as the type of return values of methods in the class, then the design of the implementation of the abstract class’s methods can proceed concurrently with the implementation of the details of the methods of the class during coding.

Clearly the determination of the abstract interface of a class that is to be used by another class is on the critical path, while coding the details of a member function that uses this interface.

A similar situation occurs at many places in every software development life cycle. You will be asked to study this point in the exercises.