WVU LDCSEE
WVU LDCSEE
CS 430
CS 430
CS 430
CS 430
Project Scheduling and Tracking
Project Scheduling and Tracking
copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
For University Use Only
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
Why Are Projects Late?
Why Are Projects Late?
an unrealistic deadline established by someone outside the
an unrealistic deadline established by someone outside the
software development group
software development group
changing customer requirements that are not reflected in
changing customer requirements that are not reflected in
schedule changes;
schedule changes;
gg
an honest underestimate of the amount of effort and/or the
an honest underestimate of the amount of effort and/or the
number of resources that will be required to do the job;
number of resources that will be required to do the job;
predictable and/or unpredictable risks that were not considered
predictable and/or unpredictable risks that were not considered
when the project commenced;
when the project commenced;
technical difficulties that could not have been foreseen in
technical difficulties that could not have been foreseen in
advance;
advance;
human 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;
miscommunication among project staff that results in delays;
g p j
g p j
y
y
a failure by project management to recognize that the project is
a failure by project management to recognize that the project is
falling behind schedule and a lack of action to correct the
falling behind schedule and a lack of action to correct the
problem
Scheduling Principles
Scheduling Principles
compartmentalization
compartmentalization
—
—define distinct tasks
define distinct tasks
interdependency
interdependency
—
—indicate task interrelationship
indicate task interrelationship
interdependency
interdependency
indicate task interrelationship
indicate task interrelationship
effort validation
effort validation
—
—be sure resources are available
be sure resources are available
defined responsibilities
defined responsibilities
—
—people must be assigned
people must be assigned
defined outcomes
defined outcomes
—
—each task must have an output
each task must have an output
defined milestones
defined milestones
—
—review for quality
review for quality
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
Effort and Delivery Time
Effort and Delivery Time
Effort Cost Impossible region Ed Eo Ea = m ( td4 / ta4) Ea = effort in person-months t d = nominal delivery time for schedule t o = optimal development time (in terms of cost) t a = actual delivery time desired
t d Tmin = 0.75T d
Effort Allocation
Effort Allocation
40
40--50%
50%
“front end” activities
“front end” activities
customer communication
customer communication
customer communication
customer communication
analysis
analysis
design
design
review and modification
review and modification
construction activities
construction activities
coding or code generation
coding or code generation
testing and installation
testing and installation
15
15--20%
20%
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
30
30--40%
40%
testing and installation
testing and installation
unit, integration
unit, integration
white
white--box, black box
box, black box
regression
regression
Defining Task Sets
Defining Task Sets
determine type of project
determine type of project
assess the degree of rigor required
assess the degree of rigor required
assess the degree of rigor required
assess the degree of rigor required
identify adaptation criteria
identify adaptation criteria
Task Set Refinement
Task Set Refinement
1.1
Concept scoping
determines the
overall scope of the project.
T k d fi iti T k 1 1 C t S i 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;
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
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; 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
is refined to
Define a Task Network
Define a Task Network
I.3a Tech. Risk Assessment I.5a Concept Implement. I.1 Concept scoping I.3b Tech. Risk Assessment I.3c Tech. Risk Assessment
Three I.3 tasks are Three I.3 tasks are li d i ll l t I.4 Proof of Concept I.5b Concept Implement. I.5c Concept Implement. I.2 Concept planning I.6 Customer Reaction Integrate a, b, c applied in parallel to 3 different concept functions applied in parallel to 3 different concept functions
Timeline Charts
Timeline Charts
Tasks Week 1 Week 2 Week 3 Week 4 Week n
Task 1 Task 1 Task 2 Task 3 Task 4Task 5 Task 6 Task 7 Task 8 Task 9
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
Task 10 Task 11 Task 12
Use Automated Tools to
Use Automated Tools to
Derive a Timeline Chart
Derive a Timeline Chart
I.1.1 Identify need and benefits Meet with customers Identify needs and project constraints E t bli h d t t t t
week 1 week 2 week 3 week 4 Work tasks week 5
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 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
Schedule Tracking
Schedule Tracking
conduct periodic project status meetings in which each team
conduct periodic project status meetings in which each team
member reports progress and problems.
member reports progress and problems.
evaluate the results of all reviews conducted throughout the
evaluate the results of all reviews conducted throughout the
evaluate the results of all reviews conducted throughout the
evaluate the results of all reviews conducted throughout the
software engineering process.
software engineering process.
determine whether formal project milestones (the diamonds
determine whether formal project milestones (the diamonds
shown in Figure 24.3) have been accomplished by the
shown in Figure 24.3) have been accomplished by the
scheduled date.
scheduled date.
compare actual start
compare actual start--date to planned start
date to planned start--date for each project
date for each project
task listed in the resource table (Figure 24.4).
task listed in the resource table (Figure 24.4).
t i f
ll
ith
titi
t
bt i th i
bj ti
t i f
ll
ith
titi
t
bt i th i
bj ti
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
meet informally with practitioners to obtain their subjective
meet informally with practitioners to obtain their subjective
assessment of progress to date and problems on the horizon.
assessment of progress to date and problems on the horizon.
use earned value analysis (Section 24.6) to assess progress
quantitatively.
Progress on an OO Project
Progress on an OO Project--II
Technical milestone: OO analysis completed
Technical milestone: OO analysis completed
All classes and the class hierarchy have been defined and reviewed.All classes and the class hierarchy have been defined and reviewed.
Class attributes and operations associated with a class have been defined Class attributes and operations associated with a class have been defined
and reviewed. and reviewed.
Class relationships (Chapter 8) have been established and reviewed.Class relationships (Chapter 8) have been established and reviewed.
A behavioral model (Chapter 8) has been created and reviewed.A behavioral model (Chapter 8) has been created and reviewed.
Reusable classes have been noted.Reusable classes have been noted.
Technical milestone: OO design completed
Technical milestone: OO design completed
The set of subsystems (Chapter 9) has been defined and reviewed.The set of subsystems (Chapter 9) has been defined and reviewed.
Classes are allocated to subsystems and reviewedClasses are allocated to subsystems and reviewed
Classes are allocated to subsystems and reviewed.Classes are allocated to subsystems and reviewed.
Task allocation has been established and reviewed.Task allocation has been established and reviewed.
Responsibilities and collaborations (Chapter 9) have been identified.Responsibilities and collaborations (Chapter 9) have been identified.
Progress on an OO Project
Progress on an OO Project--II
II
Technical milestone: OO programming completed
Technical milestone: OO programming completed
Each new class has been implemented in code from the design model.Each new class has been implemented in code from the design model.
Extracted classes (from a reuse library) have been implemented.Extracted classes (from a reuse library) have been implemented.
Prototype or increment has been built.Prototype or increment has been built.
Technical milestone: OO testing
Technical milestone: OO testing
The correctness and completeness of OO analysis and design models has The correctness and completeness of OO analysis and design models has
been reviewed. been reviewed.
A classA class--responsibilityresponsibility--collaboration network (Chapter 8) has been developed collaboration network (Chapter 8) has been developed
and reviewed. and reviewed.
Test cases are designed and classTest cases are designed and class--level tests (Chapter 14) have been level tests (Chapter 14) have been
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
gg (( pp ))
conducted for each class. conducted for each class.
Test cases are designed and cluster testing (Chapter 14) is completed and Test cases are designed and cluster testing (Chapter 14) is completed and
the classes are integrated. the classes are integrated.
System level tests have been completed.System level tests have been completed.
Earned Value Analysis (EVA)
Earned Value Analysis (EVA)
Earned value
is a measure of progress
is a measure of progress
enables us to assess the “percent of completeness” of a project
using quantitative analysis rather than rely on a gut feeling
“provides accurate and reliable readings of performance from as
Computing Earned Value
Computing Earned Value--II
The
The
budgeted cost of work scheduled
budgeted cost of work scheduled
(BCWS) is
(BCWS) is
determined for each work task represented in the
determined for each work task represented in the
determined for each work task represented in the
determined for each work task represented in the
schedule.
schedule.
BCWS
BCWS
iiis the effort planned for work task
is the effort planned for work task
i.
i.
To determine progress at a given point along the project
To determine progress at a given point along the project
schedule, the value of BCWS is the sum of the BCWS
schedule, the value of BCWS is the sum of the BCWS
iivalues for
values for
all work tasks that should have been completed by that point in
all work tasks that should have been completed by that point in
time on the project schedule.
time on the project schedule.
Th BCWS
l
f
ll
k
k
d
Th BCWS
l
f
ll
k
k
d
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
The BCWS values for all work tasks are summed to
The BCWS values for all work tasks are summed to
derive the
derive the
budget at completion,
budget at completion,
BAC. Hence,
BAC. Hence,
BAC =
BAC =
∑
∑
(BCWS
(BCWS
kk) for all tasks
) for all tasks k
k
Computing Earned Value
Computing Earned Value--II
II
Next, the value for
Next, the value for
budgeted cost of work performed
budgeted cost of work performed
(BCWP) is computed.
(BCWP) is computed.
The value for BCWP is the sum of the BCWS values for all work tasks that have 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.
actually been completed by a point in time on the project schedule.
“the distinction between the BCWS and the BCWP is that the former
“the distinction between the BCWS and the BCWP is that the former
represents the budget of the activities that were planned to be completed
represents the budget of the activities that were planned to be completed
and the latter represents the budget of the activities that actually were
and the latter represents the budget of the activities that actually were
completed.” [WIL99]
completed.” [WIL99]
Given values for BCWS, BAC, and BCWP, important progress indicators
Given values for BCWS, BAC, and BCWP, important progress indicators
can be computed:
can be computed:
Schedule performance index, SPI = BCWP/BCWSSchedule performance index, SPI = BCWP/BCWS
Schedule variance SV = BCWPSchedule variance SV = BCWP –– BCWSBCWS
Schedule variance, SV BCWP Schedule variance, SV BCWP BCWSBCWS
SPI is an indication of the efficiency with which the project is utilizing scheduled SPI is an indication of the efficiency with which the project is utilizing scheduled
resources. resources.
Computing Earned Value
Computing Earned Value--III
III
Percent scheduled for completion = BCWS/BAC
Percent scheduled for completion = BCWS/BAC
provides an indication of the percentage of work that should have beenprovides an indication of the percentage of work that should have been
provides an indication of the percentage of work that should have been provides an indication of the percentage of work that should have been
completed by time completed by time t.t.
Percent complete = BCWP/BAC
Percent complete = BCWP/BAC
provides a quantitative indication of the percent of completeness of the project at provides a quantitative indication of the percent of completeness of the project at
a given point in time, a given point in time, t.t.
Actual cost of work performed,
Actual cost of work performed,
ACWP
ACWP
, is the sum of the effort actually
, is the sum of the effort actually
expended on work tasks that have been completed by a point in time on the
expended on work tasks that have been completed by a point in time on the
project schedule It is then possible to compute
project schedule It is then possible to compute
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
project schedule. It is then possible to compute
project schedule. It is then possible to compute
Cost performance index, CPI = BCWP/ACWPCost performance index, CPI = BCWP/ACWP