(3) Conducting case studies.
2 UNCERTAINTY OF SOFTWARE
PROCESS AND
RESCHEDULING STRATEGIES
Two common rescheduling strategies are known:
dynamics scheduling strategies and predictive-
reactive strategy (
Pfeiffer, 2006). In this paper, we
focus on predictive-reactive strategies. Predictive-
reactive strategy includes periodic, event-driven and
hybrid. When a specified event occurs during
schedule execution which has significant affect on
the further execution, the schedule must be revised.
Such an event in software project can be
turnover of essential personnel, technical approaches
that may not work, unavailability of development or
testing equipment and facilities (
Kitchenham, 1997).
Successful project control is based on the tracking of
actual execution versus the project plan. Traditional
EVA (Earned Value Analysis) techniques can be
adopted for comparing a project plan and its
execution. When a threshold reaches, rescheduling
happens.
3 OUR APPROACH
3.1 The Model
In our software project scheduling model, a project
is represented as a Task Precedence Graph (TPG).
z A TPG is an acyclic directed graph consisting
of a set of tasks V={T
1
, T
2
, …, T
n
} and a set of
task precedence relations P={ (P
ij
); i<>j,
1<=i<=n, 1<=j<=n}, where P
ij
= 1 if T
i
must be
first completed before T
j
can start, and zero if
not.
z Associated with each task T
k
is the estimated
effort which can be obtained from any known
estimation methods (such as COCOMO and
COCOMO II) and required skills.
Resource modeling focuses on team members for
a software project since they are major resources for
any software project. Employees have a list of skills
they possess, their salary rates, and their maximum
workloads (a limit to the amount of work load they
can be assigned). Proficiency levels of skills are not
described since our previous research experiences
suggest that too detailed modeling techniques lack of
practical usage in dynamic situations. The combined
skill set of the employees assigned to T
i
(SK_EMP(i)) should include all the skills required
by the task (SK_TASK(i)), i.e., SK _ EMP(i) ⊇ SK
_TASK(i).
Efficiency
There are many performance objectives for project
execution. The most common ones are minimum
project duration and minimum total cost. Our
efficiency measure is shown in Equation 1.
Efficiency = W1/OverLoad
norm
+
W2/Cost
norm
+ W3/Time
norm
(1)
OverLoad (minimum level of overtime) is the
amount of time worked beyond the individual over
time limits which is summed over all employees, and
it is treated as a global objective for a project.
OverLoad
norm
is computed by normalizing Overload.
When applying GA in Section 3.2, OverLoad
norm
is
achieved by dividing overload by the maximum
overload in the population. Similarly, cost and time
are also normalized as Cost
norm
and Time
norm
. Cost
(minimum cost) is the total labor cost of performing
the project, computed using the labor rates of each
resource and the hours applied to the tasks. Time
(minimum of time span) is the total time span
required to finish the project, from the start of the
first task until the end of the last. W1, W2 and W3
are the weights chosen by managers for these three
sub-objectives respectively.
Stability
When only considering efficiency measure of a
schedule, a newly generated schedule will be often
radically different from the initial one. Then the high
cost of the changing staffing profile can not be
neglected under this case. Practically speaking,
managers are in favor of rescheduling strategies
addressing continuity.
To minimize the impact of disruptions induced
by new schedule, the performance measurement,
stability, is applied. Two kinds of stability are
recognized, i.e. ex post stability, ex ante stability
(
Herroelen, 2005). Ex post stability is considered here.
There are several possible solutions for stability.
Here Equation 2 (
Pfeiffer, 2006) is adapted in our
model to calculate stability in our objective function.
The value is achieved by adding starting time
deviation and actuality penalty.
A STABILITY AND EFFICIENCY ORIENTED RESCHEDULING APPROACH FOR SOFTWARE PROJECT
MANAGEMENT
163