Page 111 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 5: Software Project Planning

5.6 Project Scheduling and Staffing Notes

After establishing a goal on the effort front, we need to establish the goal for delivery schedule.
With the effort estimate (in person-months), it may be tempting to pick any project duration
based on convenience and then fix a suitable team size to ensure that the total effort matches the
estimate. However, as is well known now, person and months are not fully interchangeable in
a software project. Person and months can be interchanged arbitrarily only if all the tasks in the
project can be done in parallel, and no communication is needed between people performing the
tasks. This is not true for software projects—there are dependencies between tasks (e.g., testing
can only be done after coding is done), and a person performing some task in a project needs to
communicate with others performing other tasks. As Brooks has pointed out, “man and months
are identical only for activities that require no communication among men, like sowing wheat
or reaping cotton. This is not even approximately true of software.”
However, for a project with some estimated effort, multiple schedules (or project duration) are
indeed possible. For example, for a project whose effort estimate is 56 person-months, a total
schedule of 8 months is possible with 7 people. A schedule of 7 months with 8 people is also
possible, as is a schedule of approximately 9 months with 6 people. (But a schedule of 1 month
with 56 people is not possible. Similarly, no one would execute the project in 28 months with 2
people.) In other words, once the effort is fixed, there is some flexibility in setting the schedule
by appropriately staffing the project, but this flexibility is not unlimited. Empirical data also
suggests that no simple equation between effort and schedule fits well.

The objective is to fix a reasonable schedule that can be achieved (if suitable number of resources is
assigned). One method to determine the overall schedule is to determine it as a function of effort.
Such function can be determined from data from completed projects using statistical techniques
like fitting a regression curve through the scatter plot obtained by plotting the effort and schedule
of past projects. This curve is generally nonlinear because the schedule does not grow linearly
with effort. Many models follow this approach. The IBM Federal Systems Division found that
the total duration, M, in calendar months can be estimated by M = 4.1E.36. In COCOMO, the
equation for schedule for an organic type of software is M = 2.5E.38. As schedule is not a function
solely of effort, the schedule determined in this manner is essentially a guideline.
Another method for checking a schedule for medium-sized projects is the rule of thumb called
the square root check. This check suggests that the proposed schedule can be around the square
root of the total effort in person-months. This schedule can be met if suitable resources are
assigned to the project. For example, if the effort estimate is 50 person-months, a schedule of
about 7 to 8 months will be suitable. From this macro estimate of schedule, we can determine
the schedule for the major milestones in the project. To determine the milestones, we must first
understand the manpower ramp-up that usually takes place in a project. The number of people
that can be gainfully utilized in a software project tends to follow the Rayleigh curve. That is,
in the beginning and the end, few people are needed on the project; the peak team size (PTS)
is needed somewhere near the middle of the project; and again fewer people are needed after
that. This occurs because only a few people are needed and can be used in the initial phases
of requirements analysis and design. The human resources requirement peaks during coding
and unit testing, and during system testing and integration, again fewer people are required.
Often, the staffing level is not changed continuously in a project and approximations of the
Rayleigh curve are used: assigning a few people at the start, having the peak team during the
coding phase, and then leaving a few people for integration and system testing. If we consider
design and analysis, build, and test as three major phases, the manpower ramp-up in projects
typically resembles the function shown in Figure 5.7. For ease of scheduling, particularly for

LOVELY PROFESSIONAL UNIVERSITY 105