Planning and Scheduling

Objectives

• Develop the necessary understanding and

skills to produce and manage a simple project
schedule.

Software Process
Management
 Planning and Scheduling
Scheduling and Planning

• So far we have a project for which we have estimated

duration and effort based on a high level understanding
of what needs to be done.
• The majority of projects are 'completed' late, if at all.
• A project schedule is required to ensure that required
project commitments are met.
• A schedule is required to track progress toward
achieving these commitments.

Software Process
Management
 Planning and Scheduling
Why Software Is Delivered Late?

• An unrealistic deadline
• Changing but unpredicted customer requirements
• Underestimation of efforts needed
• Risks not considered at the project start
• Unforeseen technical difficulties
• Unforeseen human difficulties
• Miscommunication among project staff
• Failure to recognize that project is falling behind schedule

Software Process
Management
 Planning and Scheduling
“One day a time”
 All technical projects involve 100s of small tasks
 Some tasks do no affect the project completion
 Other tasks are critical for project completion
 Project manager must:
 define all project tasks
 build a network that depicts their interdependence
 identify the critical tasks
 track the progress of these tasks
 recognize the delay “one day at a time”

Software Process
Management
 Planning and Scheduling
Two different Perspectives to view
Scheduling

End
End date
date for
for Only
Only Rough
Rough
completion
completion hashas time-frame
time-frame isis
been
been finalized
finalized given
given

Software Process
Management
 Planning and Scheduling
Basic Principles for SE Scheduling
• Compartmentalization – define distinct tasks
• Interdependency- parallel and sequential tasks
• Time allocation - assigned person days, start time,
ending time)
• Effort validation - be sure resources are available
• Defined responsibilities — people must be
assigned
• Defined Outcomes- each task must have an output
• Defined milestones - review for quality
Software Process
Management
 Planning and Scheduling
People and Effort

“If
“If we
we fall
fall behind
behind schedule
schedulewe
wecan can always
always add
addmore
more
programmers
programmers and and catch
catch to
to late
late in
in the
the project”
project”

Has a disruptive effect on the project

Schedules slip even further

Software Process
Management
 Planning and Scheduling
People and Effort

The
The relationship
relationship between
between the
the number
number of
of
people
people working
working inin software
software project
project and
and
overall
overall productivity
productivity isis
not
not linear
linear

Fewer
Fewerpeople
peopleand
and
longer
longertime
timeperiod
periodisisaa
better
betteroption
optionfor
forsoftware
software
development
development
Software Process
Management
 Planning and Scheduling
Effort Distribution

40-20-40
40-20-40

Front-end
Analysis & Back-end
Design testing
Coding

Software Process
Management
 Planning and Scheduling
Effort Allocation

• “front end” activities

– customer communication
40-50% – analysis
– design
– review and modification
• construction activities
– coding or code generation
15-20%
• testing and installation
– unit, integration
– white-box, black box
– regression
30-40%

Software Process
Management
 Planning and Scheduling
Effort Distribution
PI
(2-3%)
RA
RA
(20-25%)
Testing
Testing
(30 - 40%)

(20-25%)
SD
SD
(15 -20%)
Coding
Coding
Software Process
Management
 Planning and Scheduling
Scheduling and Planning
In order to make a schedule, the following tasks
must be completed:
• Identify manageable activities and tasks by decomposing the process and
the product.
• Determine which tasks are dependent on the completion of others. (Which
activities must occur in sequence and which can occur concurrently.)
• Allocate each task a number of work-units (often person-days), a start
date and a completion date.
• Define responsibilities for the tasks (allocate them to a person or persons).
• Define outcomes of the tasks (deliverables) and milestones for the
schedule.
• Review the proposed tasks, their effort allocation and start and end dates
with the people involved to ensure there are no conflicts and over
allocation.

Software Process
Management
 Planning and Scheduling
Identifying Tasks

The first step :

identify the tasks required to be performed.
These tasks will comprise software engineering activities broken down for
product functions.
A schedule is not a fixed entity and as such it will be refined as a project
progresses.
• Initially rough
a project schedule usually refers to the work tasks, deliverables and milestones for
major software engineering activities and major product functions
• is refined in detail
as the project progresses to refer to specific tasks and activities that must be
completed for those major activities and functions.

Software Process
Management
 Planning and Scheduling
Selecting Project Tasks

No set of tasks is appropriate for all projects.

The set of tasks that are appropriate for a project depends on a
number of factors. These include:
• The process model selected. An iterative development model would require
different tasks, etc... than would a waterfall model or rapid application
development model.
• The type of project. A new development project has a different set of tasks
to a maintenance project or to a concept development.
• The size and complexity of the product.
• The rigor required in development. This is a factor generally determined by
things like product size, mission criticality, stability of requirements, etc...

Software Process
Management
 Planning and Scheduling
Selecting Project Tasks

Many software engineering tasks have deliverables.

For example, the Software Requirements Specification (SRS) might be the deliverable
produced as a result of requirements analysis.
Milestones are objectively identifiable points in a project. They
are generally associated with the completion of a major activity. It
is often a good idea to associate them with deliverables.
For example, a milestone might be established at initial requirements sign-off.
This checkpoint will come after the requirements documents have been
produced, inspected, corrected and signed off on. The only rule for establishing
a checkpoint is that you must be able to objectively determine if that milestone
has been reached.

Software Process
Management
 Planning and Scheduling
Selecting Project Tasks
• Milestone = end-point of a specific, distinct software process activity or task
(for each milestone a report should be presented to the management)

A C T IVT I
E
S
• Deliverable = project result delivered to the client

F
eF
aerastsupiibbodrllttyyR
eR q
aedquunfiirrnleeym
itonnttssdE
sm P
evvrroaelltupym
p e
n
ttrionAD e
trcdhissuteidggcynnuralReseppqquucciirfrfeem
sR iainonottss
am
• In order to establish milestones the phases of the software process phases
need be divided in basic activities/tasks.

M IL EST O
N
E
S Software Process
Management
 Planning and Scheduling
Defining Task Sets
• determine type of project
• assess the degree of rigor required
– identify adaptation criteria
– compute task set selector (TSS) value
– interpret TSS to determine degree of rigor
• select appropriate software engineering tasks

Software Process
Management
 Planning and Scheduling
Software Project Types

• Concept Development projects

• New Application Development Projects

• Application Enhancement Project

• Application Maintenance Project

• Reengineering Project
Software Process
Management
 Planning and Scheduling
Degree of Rigor

Casual
Casual
Structured
Structured
•• Minimum
Minimum task set isisStrict
task set Strict
required
required ••Framework
Framework••activities
activities Quick Reaction
will be applied Full
Full Quick
process
process will
will Reaction
be
be
Umbrellawill
••Umbrella tasksbeare
tasks applied
are applied
applied ••Process
Process framework
framework
minimized •
minimized•Umbrella
Umbrella taskstasks are
are of will be applied
••Degree
Degree of discipline
will be applied
discipline
applied
applied
••Documentation ensures
Documentation ensures high
high
••
quality
quality
Only
Only essential
essential tasks
tasks
requirements
•
requirements are
Documentation
are
•Documentation and
and will be undertaken
reduced ••All
All umbrellawill
umbrella activities
be undertaken
activities
reduced measurement
measurement tasks
willtasks
be applied
••Basic will
will be
be done
done will
in
in a
a be applied
•• Documentation
Documentation will
will
principles
Basic principles of
of be provided after
SE are streamlines
streamlines
applicable ••Robust
manner
manner
Robust work
be
work products
provided
products after
SE are applicable will product
product delivery
will bebe produced
produced delivery

Software Process
Management
 Planning and Scheduling
Adaptation Criteria
• Size of the Project
• Number of potential users
• Mission criticality
• Application Longevity
• Stability requirements
• Ease of communication 1 5
• Maturity of technology
• Performance constraints
• Embedded and non-embedded characteristics
• Project staff
• Reengineering factors
Software Process
Management
 Planning and Scheduling
Task Set selector
• Based on adaptation criteria, TSS is computed

TSS > 1.2 Casual

1.0 < TSS < 3.0 Structured

TSS > 2.4 Strict

Software Process
Management
 Planning and Scheduling
Activity Network Diagrams

An activity network diagram provides a notation for documenting

• a network of tasks needed to complete a project,
• their interdependencies
• the times required for each task.
There are a number of activity network techniques which are
similar in nature. The most commonly used include PERT (Project
Evaluation and Review Technique) and CPM (Critical Path
Method).

Software Process
Management
 Planning and Scheduling
Pert Chart

A simple PERT chart comprises circles (nodes) to

represent events within the development lifecycle
For example commencement / completion of tasks, and
lines (edges) which represent the the tasks. The lines are
additionally labeled by the estimated duration of the task.
Note: there are a number of variations to this notation. A
real PERT chart shows earliest time to completion, latest
time to completion, and slack in the circles also.

Software Process
Management
 Planning and Scheduling
How to construct a PERT chart

The basic steps to constructing a PERT chart are:

• Identify tasks and estimate duration of times
• Identify a single start and end event
• Arrange events in sequence (give events a unique number)
• Establish start and finish times of each task. Keep in mind the
estimates made for duration and effort.
• Determine float
• Revise

Software Process
Management
 Planning and Scheduling
Pert Chart

As an example of using a PERT chart, consider the following simple chart

showing a project with tasks A,B,C,D and E
This diagram states that tasks A,B,C and E will take 2 days (assume d is
abbreviation for days) and task D has a planned duration of 5 days.
Task D is dependent on completion of task B, etc.

2 C 4
2d
A
E
2d
2d

1
5

B
D
2d
5d
3

Software Process
Management
 Planning and Scheduling
The Critical Path

The critical path is the path between the start event and end
event which takes the longest time.
Note that:
• No task on the critical path can take longer without extending the end date
of the project.
• Tasks on the critical path are called critical tasks.
• No critical task can have any slack.
• Tasks on the critical path must be carefully monitored.

Software Process
Management
 Planning and Scheduling
The Critical Path
In the example above the critical path can be described by events 1,3 and 5 or by tasks B,D.
This is because the time to reach the end event (5) on this path is longer than any other path.
This means that task B must take no longer than 2 days and task D no longer than 5 days or the
end date for event E will need to be extended.
The duration of the other path is 6 days. Because the critical path is 7 days, there is slack (or
float) of one day on the other path.
This means that this path can take 1 day longer than planned.
That is, any one task on this path (A,C or E) can take 1 day longer than expected. Note this
slack must be shared between the tasks on this other path. They can not all take an extra day

2 C 4
2d
A
E
2d
2d

1
5

B
D
2d
5d
3

Software Process
Management
 Planning and Scheduling
Project Scheduling

Program
Critical
Evaluation
Path
and Review
Method
Technique
(PERT) (CPM)

Software Process
Management
 Planning and Scheduling
Project Scheduling

Both techniques (PERT and CPM) are driven by

information already developed in earlier project
planning activities:
– Estimates of efforts
– Decomposition of product function
– selection of appropriate process model and task set
– Decomposition of tasks

Software Process
Management
 Planning and Scheduling
Project Scheduling

• Both PERT and CPM provides quantitative tools to

– determine the critical path
– establish the most likely time estimated for
individual tasks by applying statistical models
– calculate boundary time (window) for a particular
task

Software Process
Management
 Planning and Scheduling
Project Scheduling

Important
Important boundary
boundary times
times for
for PERT
PERT and
and CPM
CPM

Total float - the

Earliest time a
amount of surplus
task can begin Earliest finish
time allowed in
when all - the sum of the scheduling tasks so
preceding tasks earliest start
that the network
are completed and the task
critical path is
in shores duration
maintained on
possible time
Latest time for Latest schedule
task initiation finish - the
before the latest start
minimum project time added
completion time to task
is delayed duration
Software Process
Management
 Planning and Scheduling
Gantt Charts

GANTT charts are a project planning tool that can be used to represent the
timing of tasks required to complete a project.
It describes similar information to a PERT chart.
Here is one that was produced automatically with a project management tool from
the PERT chart info above:

Software Process
Management
 Planning and Scheduling
Project Table

WorkTasksPlannedStartActualStartPlannedCompleteActualCompletePersonAssignedEffortNe

Software Process
Management
 Planning and Scheduling
Tracking the Project Schedule
• It is a road map for the Software Project
• It defines the tasks and milestones
• Tracking can be done by:
– Conducting periodic project status meetings
– Evaluating the results of all reviews
– Determining whether milestones were reached by the scheduled date
– Compare actual start date to planned start date
– Meeting informally with professionals to get their subjective opinion
– Using earned value analysis

Software Process
Management
 Planning and Scheduling
Tracking Earned Value

The earned value system provides a common value scale for every
task, regardless of the type of work being performed.
The total hours to do the whole project are estimated, and every
task is given an earned value based on its estimated percentage of
the total.
Basically, earned value is useful as it provides a quantitative
technique of assessing progress on the project as a whole (even
when tasks are completed in an order that differs from the original
schedule)

Software Process
Management
 Planning and Scheduling
Tracking Earned Value
Example
Consider the following project

Software Process
Management
 Planning and Scheduling
Calculating the planned Value
The planned value for a task is the estimated percentage of the planned duration
of that task of the total planned duration of all tasks.

Planned ValueT = DT / TD
where T is a task, DT is the duration of T and TD is the total planned duration of
all tasks.

Applying this formula we calculate the planned value for the planning task from
the above table. We have estimated that planning will take 180 minutes. The
total duration of all of our estimates for development is 2305 minutes. The
planned value for the planning task by the formula above is, therefore, given by
Planned Value = 180/2305 ~ 7.81%

Software Process
Management
 Planning and Scheduling
Calculating the planned Value
We write this value in the planned value (unit) column for the planning task. We do the same for all of
the tasks in the plan. The total of all of the unit planned values will be 100% if this is done correctly.

Software Process
Management
 Planning and Scheduling
Calculating the planned Value
We also wish to document when we expect each task to be completed.
In this example, this has been done by filling in the week number in the planned
completion column.
In order to track progress against this plan, we should have an idea of what percentage
complete we expect to be at the end of each week.
Notice that in the table below (most of) our tasks are listed in order of expected
completion (not necessary, but advisable to start with).
We keep a cumulative total of the planned value in the cumulative planned value column.
We can use this column to determine what percentage of the project will be complete by
the end of week 3, for example.
We can see that the sum of all of the planned values for tasks planned to be complete
before the end of week 3 is approx. 48.81% (because the tasks are in order, the
cumulative planned value for the last week 3 entry gives us this number - if the tasks are
listed unordered by completion date, the sum must be calculated by adding the planned
values of all tasks due to be completed before the date in question). In the next section,
we describe how to use this information to track progress.

Software Process
Management
 Planning and Scheduling
Tracking a Project with Earned Value
Ok we have reached the end of the second week on this project and we need to know how our progress toward
completion on time.
We haven't done everything in the order in which it was planned, so this may not be easy to guess at.
We can use the concept of an earned value.
Earned value is assigned only to completed tasks.
If I have completed a task with a planned value of p%, then the earned value for that task is p%. Incomplete
tasks have no earned value.

In the example below, compiled at the end of the second week, we see that the group has completed the following
tasks with their associated earned value:
– Planning - 7.81%
– Scope - 2.64%
– Product Features - 2.64%
– User Profile - 1.98%
– Assumptions - 2.64%
– UI requirements - 5.21%

By summing the earned values for the completed tasks we determine that at the end of week 2, the cumulative
earned value (the percent complete) is 7.81+2.64+2.64+1.98+2.64+5.21=22.91%.

Now, knowing the earned value the project group can determine if they are ahead, behind on on schedule to
complete on time

Software Process
Management
 Planning and Scheduling
Tracking a Project with Earned Value
Looking at the cumulative planned value in the table, we see that at the end of week 2 to be on schedule,
the group should have been 33.19% complete.
By the above calculation that they are actually only 22.91% complete, it appears that the project is falling
behind schedule.

Software Process
Management
 Planning and Scheduling
Tracking a Project with Earned Value

Knowing this allows the project team to take action.

Such action may involve

– adjusting work practices,
– negotiating with the client for an extension to the deadline,
– etc...

It is argued that earned value provides accurate and reliable readings of

performance as early as 15% into a project. This kind of quantitative project
management is essential if projects are to be consistently delivered on time.

Software Process
Management
Planning and Scheduling

Tracking the Project Schedule

Administer
Project
Resources

Control Cope with

problems

Direct
Project
staff

Software Process
Management
Planning and Scheduling
Tracking the Project Schedule

Project is on
schedule and
within budget Additional
Additionalresources
resources
focussed
focussedon
onproblem
problem
area
area
Project Tracking
Staff
Staffmay
maybe
be
redeployed
redeployed
Problem
diagnosed Project
ProjectSchedule
Schedulecan
can
be
beredefined
redefined
Software Process
Management