Chapter 27

n Project Scheduling
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1
Why Are Projects Late?
n an unrealistic deadline established by someone outside the
software development group
n changing customer requirements that are not reflected in
schedule changes;
n an honest underestimate of the amount of effort and/or the
number of resources that will be required to do the job;
n predictable and/or unpredictable risks that were not considered
when the project commenced;
n technical difficulties that could not have been foreseen in
advance;
n human difficulties that could not have been foreseen in advance;
n miscommunication among project staff that results in delays;
n a failure by project management to recognize that the project is
falling behind schedule and a lack of action to correct the
problem

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2
Scheduling Principles
n compartmentalization—define distinct tasks
n interdependency—indicate task
interrelationship
n effort validation—be sure resources are
available
n defined responsibilities—people must be
assigned
n defined outcomes—each task must have an
output
n defined milestones—review for quality
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3
 Effort and Delivery Time

Effort
Cost
Ea = m (t d4 / t a4)

Impossible Ea = effort in person-months

region t d = nominal delivery time for schedule
t o = optimal development time (in terms of cost)
t a = actual delivery time desired
Ed

Eo

td to development time
Tmin = 0.75T d

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4
 Effort Allocation
n “front end” activities
n customer communication
40-50% n analysis
n design
n review and modification
n construction activities
n coding or code
15-20% generation
n testing and installation
n unit, integration
n white-box, black box
n regression
30-40%

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5
Defining Task Sets
n determine type of project
n assess the degree of rigor required
n identify adaptation criteria
n select appropriate software engineering tasks

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6
 Task Set Refinement
1.1 Concept scoping determines the overall scope of the
project.
Task definition: Task 1.1 Concept Scoping
1.1.1 Identify need, benefits and potential customers;
1.1.2 Define desired output/control and input events that drive the application;
Begin Task 1.1.2
1.1.2.1 FTR: Review written description of need
FTR indicates that a formal technical review (Chapter 26) is to be conducted.
1.1.2.2 Derive a list of customer visible outputs/inputs
1.1.2.3 FTR: Review outputs/inputs with customer and revise as required;
endtask Task 1.1.2
1.1.3 Define the functionality/behavior for each major function;
Begin Task 1.1.3
1.1.3.1 FTR: Review output and input data objects derived in task 1.1.2;
1.1.3.2 Derive a model of functions/behaviors;
1.1.3.3 FTR: Review functions/behaviors with customer and revise as required;
endtask Task 1.1.3
1.1.4 Isolate those elements of the technology to be implemented in software;
is refined to 1.1.5 Research availability of existing software;
1.1.6 Define technical feasibility;
1.1.7 Make quick estimate of size;
1.1.8 Create a Scope Definition;
endTask definition: Task 1.1

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7
Define a Task Network

I.5a
I.3a
Concept
Tech. Risk
Implement.
Assessment

I.1 I.2 I.3b I.4 I.5b I.6

Concept Integrate Customer
Concept Concept Tech. Risk Proof of
Implement. a, b, c Reaction
scoping planning Assessment Concept

I.3c I.5c
Tech. Risk Concept
Assessment Implement.

Three I.3 tasks are Three I.3 tasks are

applied in parallel to applied in parallel to
3 different concept 3 different concept
functions functions

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 8
 Timeline Charts
Tasks Week 1 Week 2 Week 3 Week 4 Week n

Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9
Use Automated Tools to
Derive a Timeline Chart
Work tasks week 1 week 2 week 3 week 4 week 5
I.1.1 Identify need and benefits
Meet with customers
Identify needs and project constraints
Establish product statement
Milestone: product statement defined
I.1.2 Define desired output/control/input (OCI)
Scope keyboard functions
Scope voice input functions
Scope modes of interaction
Scope document diagnostics
Scope other WP functions
Document OCI
FTR: Review OCI with customer
Revise OCI as required;
Milestone; OCI defined
I.1.3 Define the functionality/behavior
Define keyboard functions
Define voice input functions
Decribe modes of interaction
Decribe spell/grammar check
Decribe other WP functions
FTR: Review OCI definition with customer
Revise as required
Milestone: OCI defintition complete
I.1.4 Isolate software elements
Milestone: Software elements defined
I.1.5 Research availability of existing software
Reseach text editiong components
Research voice input components
Research file management components
Research Spell/Grammar check components
Milestone: Reusable components identified
I.1.6 Define technical feasibility
Evaluate voice input
Evaluate grammar checking
Milestone: Technical feasibility assessed
I.1.7 Make quick estimate of size
I.1.8 Create a Scope Definition
Review scope document with customer
Revise document as required
Milestone: Scope document complete

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 10
 Schedule Tracking
n conduct periodic project status meetings in which
each team member reports progress and problems.
n evaluate the results of all reviews conducted
throughout the software engineering process.
n determine whether formal project milestones (the
diamonds shown in Figure 27.3) have been
accomplished by the scheduled date.
n compare actual start-date to planned start-date for
each project task listed in the resource table (Figure
27.4).
n meet informally with practitioners to obtain their
subjective assessment of progress to date and
problems on the horizon.
n use earned value analysis (Section 27.6) to assess
progress quantitatively.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach,
7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 11
 Earned Value Analysis (EVA)
n Earned value
n is a measure of progress
n enables us to assess the “percent of completeness”
of a project using quantitative analysis rather than
rely on a gut feeling
n “provides accurate and reliable readings of
performance from as early as 15 percent into the
project.” [Fle98]

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 12
 Computing Earned Value-I
n The budgeted cost of work scheduled (BCWS) is
determined for each work task represented in the
schedule.
n BCWSi is the effort planned for work task i.
n To determine progress at a given point along the project
schedule, the value of BCWS is the sum of the BCWSi
values for all work tasks that should have been completed
by that point in time on the project schedule.
n The BCWS values for all work tasks are summed to
derive the budget at completion, BAC. Hence,

BAC = ∑ (BCWSk) for all tasks k

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13
Computing Earned Value-II
n Next, the value for budgeted cost of work performed
(BCWP) is computed.
n The value for BCWP is the sum of the BCWS values for all
work tasks that have actually been completed by a point in time
on the project schedule.
n “the distinction between the BCWS and the BCWP is that
the former represents the budget of the activities that were
planned to be completed and the latter represents the
budget of the activities that actually were completed.”
[Wil99]
n Given values for BCWS, BAC, and BCWP, important
progress indicators can be computed:
• Schedule performance index, SPI = BCWP/BCWS
• Schedule variance, SV = BCWP – BCWS
• SPI is an indication of the efficiency with which the project is
utilizing scheduled resources.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 14
 Computing Earned Value-III
n Percent scheduled for completion = BCWS/BAC
n provides an indication of the percentage of work that should have
been completed by time t.
n Percent complete = BCWP/BAC
n provides a quantitative indication of the percent of completeness
of the project at a given point in time, t.
n Actual cost of work performed, ACWP, is the sum of the effort
actually expended on work tasks that have been completed by
a point in time on the project schedule. It is then possible to
compute
• Cost performance index, CPI = BCWP/ACWP
• Cost variance, CV = BCWP – ACWP

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 15