Software Project Scheduling

- Introduction
- Project scheduling
- Task network
- Timeline chart

Introduction
3
Eight Reasons for Late Software
Delivery
An unrealistic deadline established by someone outside the software
engineering group and forced on managers and practitioners within the
group
Changing customer requirements that are not reflected in schedule
changes
An honest underestimate of the amount of effort and /or the number of
resources that will be required to do the job
Predictable and/or unpredictable risks that were not considered when the
project commenced
Technical difficulties that could not have been foreseen in advance
Human difficulties that could not have been foreseen in advance
Miscommunication among project staff that results in delays
A failure by project management to recognize that the project is falling
behind schedule and a lack of action to correct the problem
4
Quote from Napoleon
"Any commander-in-chief who undertakes to carry out
a plan which he considers defective is at fault; he must
put forth his reasons, insist on the plan being changed,
and finally tender his resignation rather than be the
instrument of his army's downfall."
5
Handling Unrealistic Deadlines


Perform a detailed estimate using historical data from past projects;
determine the estimated effort and duration for the project

Using an incremental model, develop a software engineering strategy
that will deliver critical functionality by the imposed deadline, but delay
other functionality until later; document the plan

Meet with the customer and (using the detailed estimate) explain why
the imposed deadline is unrealistic

Offer the incremental development strategy as an alternative and offer
some options

Project Scheduling
7
General Practices
On large projects, hundreds of small tasks must occur to accomplish a larger
goal


Project manager's objectives
Define all project tasks
Build an activity network that depicts their interdependencies
Identify the tasks that are critical within the activity network
Build a timeline depicting the planned and actual progress of each task
Track task progress to ensure that delay is recognized "one day at a time"
To do this, the schedule should allow progress to be monitored and the project to
be controlled
(More on next slide)
8
General Practices (continued)
Software project scheduling distributes estimated effort across the
planned project duration by allocating the effort to specific tasks.

each task is refined into a detailed schedule where specific software
tasks are identified and scheduled

Scheduling for projects can be viewed from two different perspectives
In the first view, an end-date for release of a computer-based system has
already been established and fixed
The software organization is constrained to distribute effort within the
prescribed time frame
In the second view, assume that rough chronological bounds have been
discussed but that the end-date is set by the software engineering
organization
9
Basic Principles for Project
Scheduling
Compartmentalization

The project must be compartmentalized into a number of manageable
activities, actions, and tasks; both the product and the process are
decomposed
Interdependency

The interdependency of each compartmentalized activity, action, or task
must be determined

Time allocation
Each task to be scheduled must be allocated some number of work units
10
Basic Principles for Project
Scheduling (continued)
Effort validation
Every project has a defined number of people on the team
As time allocation occurs, the project manager must ensure that no more
than the allocated number of people have been scheduled at any given
time
Defined responsibilities
Every task that is scheduled should be assigned to a specific team member
Defined outcomes
Every task that is scheduled should have a defined outcome for software
projects such as a work product or part of a work product
Work products are often combined in deliverables
Defined milestones
Every task or group of tasks should be associated with a project milestone
A milestone is accomplished when one or more work products has been
reviewed for quality and has been approved
11
Relationship Between
People and Effort
Common management myth: If we fall behind schedule, we can always
add more programmers and catch up later in the project
This practice actually has a disruptive effect and causes the schedule to
slip even further
The added people must learn the system
The people who teach them are the same people who were earlier doing
the work
During teaching, no work is being accomplished
12
Effort Applied vs. Delivery Time
There is a nonlinear relationship between effort applied and delivery
time (Ref: Putnam-Norden-Rayleigh Curve)
Effort increases rapidly as the delivery time is reduced
Also, delaying project delivery can reduce costs significantly as shown
in the equation E = L
3
/(P
3
t
4
) and in the curve below
E = development effort in person-months
L = source lines of code delivered
P = productivity parameter (ranging from 2000 to 12000)
t = project duration in calendar months
Impossible
region

Effort
cost
Development time
t
optimal
t
theoretical
E
optimal
E
theoretical
t
minimum
13
40-20-40 Distribution of Effort
A recommended distribution of effort across the software process is 40%
(analysis and design), 20% (coding), and 40% (testing)
Work expended on project planning rarely accounts for more than 2 - 3%
of the total effort
Requirements analysis may comprise 10 - 25%
Effort spent on prototyping and project complexity may increase this
Software design normally needs 20 25%
Coding should need only 15 - 20% based on the effort applied to
software design
Testing and subsequent debugging can account for 30 - 40%
Safety or security-related software requires more time for testing
14
40-20-40 Distribution of Effort
(continued)
Testing Coding Design Analysis
P
6/1 6/4 6/23 7/14 8/2 9/5
40 20 40
Example: 100-day project
Task Network
16
Defining a Task Set
A task set is the work breakdown structure for the project
No single task set is appropriate for all projects and process models
It varies depending on the project type and the degree of rigor (based on
influential factors) with which the team plans to work
The task set should provide enough discipline to achieve high software
quality
But it must not burden the project team with unnecessary work

17
Types of Software Projects
Concept development projects
Explore some new business concept or application of some new
technology
New application development
Undertaken as a consequence of a specific customer request
Application enhancement
Occur when existing software undergoes major modifications to function,
performance, or interfaces that are observable by the end user
Application maintenance
Correct, adapt, or extend existing software in ways that may not be
immediately obvious to the end user
Reengineering projects
Undertaken with the intent of rebuilding an existing (legacy) system in
whole or in part
18
Factors that Influence a Projects
Schedule
Size of the project
Number of potential users
Mission criticality
Application longevity
Stability of requirements
Ease of customer/developer communication
Maturity of applicable technology
Performance constraints
Embedded and non-embedded characteristics
Project staff
Reengineering factors
19
Purpose of a Task Network
Also called an activity network
It is a graphic representation of the task flow for a project
It depicts task length, sequence, concurrency, and dependency
Points out inter-task dependencies to help the manager ensure
continuous progress toward project completion
The critical path
A single path leading from start to finish in a task network
It contains the sequence of tasks that must be completed on schedule if the
project as a whole is to be completed on schedule
It also determines the minimum duration of the project
20
Example Task Network
Task A
3
Task B
3
Task E
8
Task F
2
Task H
5
Task C
7
Task D
5
Task I
4
Task M
0
Task N
2
Task G
3
Task J
5
Task K
3
Task L
10
Where is the critical path and what tasks are on it?
21
Example Task Network
with Critical Path Marked
Task A
3
Task B
3
Task E
8
Task F
2
Task H
5
Task C
7
Task D
5
Task I
4
Task M
0
Task N
2
Task G
3
Task J
5
Task K
3
Task L
10
Critical path: A-B-C-E-K-L-M-N
Timeline Chart
23
Mechanics of a Timeline Chart
Also called a Gantt chart; invented by Henry Gantt, industrial engineer, 1917
All project tasks are listed in the far left column
The next few columns may list the following for each task: projected start
date, projected stop date, projected duration, actual start date, actual stop date,
actual duration, task inter-dependencies (i.e., predecessors)
To the far right are columns representing dates on a calendar
The length of a horizontal bar on the calendar indicates the duration of the
task
When multiple bars occur at the same time interval on the calendar, this
implies task concurrency
A diamond in the calendar area of a specific task indicates that the task is a
milestone; a milestone has a time duration of zero

1
None
Pred.
3/1 3/1 0 Milestone N 2
2/28 1/1 2 months Task A 1
Finish Start Duration Task Name Task #
Jan Feb Mar Apr May Jun Jul Aug Sep Oct
24
J 2 Install Inc Two K
E 5 Install Inc One F
E, I 6 Test Inc Two J
A, B 7 Analyze Inc Two G
F, K
H
G
D
C
B
A
None
Pred.
2 Close out project L
4 Code Inc Two I
5 Design Inc Two H
10 Test Inc One E
7 Code Inc One D
8 Design Inc One C
3 Analyze Inc One B
4/1 3 Establish increments A
Finish Start Duration Task Name Task #
4/1 4/8 4/15 4/22 4/29 5/6 5/13 5/20 5/27 6/3
Task network and the critical path:
Timeline chart:
CLASS EXERCISE
25
J 5/9 5/8 2 Install Inc Two K
E 5/6 5/2 5 Install Inc One F
E, I 5/7 5/2 6 Test Inc Two J
A, B 4/13 4/7 7 Analyze Inc Two G
F, K
H
G
D
C
B
A
None
Pred.
5/11 5/10 2 Close out project L
4/22 4/19 4 Code Inc Two I
4/18 4/14 5 Design Inc Two H
5/1 4/22 10 Test Inc One E
4/21 4/15 7 Code Inc One D
4/14 4/7 8 Design Inc One C
4/6 4/4 3 Analyze Inc One B
4/3 4/1 3 Establish increments A
Finish Start Duration Task Name Task #
A. Establish
Increments
3
B. Analyze
Inc One
3
C. Design
Inc One
8
D. Code
Inc One
7
F. Install
Inc One
5
G. Analyze
Inc Two
7
H. Design
Inc Two
5
I. Code
Inc Two
4
K. Install
Inc Two
2
L. Close out
Project
2
E. Test
Inc One
10
J. Test
Inc Two
6
4/1 4/8 4/15 4/22 4/29 5/6 5/13 5/20 5/27 6/3
Task network and the critical path:
Timeline chart:
SOLUTION
A-B-C-D-E-J-K-L
Load
truck
Unload
truck
Drive truck
from origin
to destination
Return
truck and
supplies
Decide on
type/size of
rental truck
Reserve
rental truck
and supplies
Arrange for
workers to
load truck
Pick up
rental truck
Arrange for
workers to
unload truck
Arrange for
person to
drive truck/car
Find lodging
with space
to park truck
Make
lodging
reservations
Determine
destination
location
Determine
date to move
out or move in
Make
decision
to move
Pack
household
goods
Plan travel
route and
overnight stops
Proposed Tasks for a Long-Distance Move of 8,000 lbs of Household Goods
Get money
to pay for
the move
Lease or buy
home at
destination
Where is the critical path and what tasks are on it?
Given a firm start date, on what date will the project be completed?
Given a firm stop date, when is the latest date that the project must start by?
17. Load
truck
19. Unload
truck
18. Drive truck
from origin
to destination
20. Return
truck and
supplies
6. Decide on
type/size of
rental truck
15. Reserve
rental truck
and supplies
7. Arrange for
workers to
load truck
16. Pick up
rental truck
9. Arrange for
workers to
unload truck
8. Arrange for
person to
drive truck/car
11. Milestone
13. Find lodging
with space
to park truck
14. Make
lodging
reservations
4. Determine
destination
location
3. Determine
date to move
out or move in
1. Make
decision
to move
10. Pack
household
goods
12. Plan travel
route and
overnight stops
Task Network for a Long-Distance Move of 8,000 lbs of Household Goods
2. Get money
to pay for
the move
5. Lease or buy
home at
destination
Where is the critical path and what tasks are on it?
Given a firm start date, on what date will
the project be completed?
Given a firm stop date, when is the latest date
that the project must start by?
28
Timeline Chart for Long Distance Move
29
Example Timeline Chart
30
Methods for Tracking the
Schedule
Qualitative approaches
Conduct periodic project status meetings in which each team member
reports progress and problems
Evaluate the results of all reviews conducted throughout the software
engineering process
Determine whether formal project milestones (i.e., diamonds) have been
accomplished by the scheduled date
Compare actual start date to planned start date for each project task listed
in the timeline chart
Meet informally with the software engineering team to obtain their
subjective assessment of progress to date and problems on the horizon
Quantitative approach
Use earned value analysis to assess progress quantitatively
31
Project Control and Time Boxing
The project manager applies control to administer project resources,
cope with problems, and direct project staff
If things are going well (i.e., schedule, budget, progress, milestones)
then control should be light
When problems occur, the project manager must apply tight control to
reconcile the problems as quickly as possible. For example:
Staff may be redeployed
The project schedule may be redefined
Severe deadline pressure may require the use of time boxing
An incremental software process is applied to the project
The tasks associated with each increment are time-boxed (i.e., given a
specific start and stop time) by working backward from the delivery date
The project is not allowed to get stuck on a task
When the work on a task hits the stop time of its box, then work ceases on
that task and the next task begins
This approach succeeds based on the premise that when the time-box
boundary is encountered, it is likely that 90% of the work is complete
The remaining 10% of the work can be
Delayed until the next increment
Completed later if required