Transcript Transparency Masters for Software Engineering: A

Chapter 24
Project Scheduling and Tracking
SWE311_Ch24 (071)
Software & Software Engineering
Slide 1
Why Are Projects Late?








an unrealistic deadline established by someone outside the
software development 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
SWE311_Ch24 (071)
Software & Software Engineering
Slide 2
How to Deal With Unrealistic Schedule
Demands




Perform a detailed project estimate for project effort and
duration using historical data.
Use an incremental process model that will deliver
critical functionality imposed by deadline, but delay
other requested functionality.
Meet with the customer and explain why the deadline is
unrealistic using your estimates based on prior team
performance.
Offer an incremental development and delivery strategy
as an alternative to increasing resources or allowing the
schedule to slip beyond the deadline.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 3
Project Scheduling Perspectives

One view is that the end-date for the software release is set
externally and that the software organization is constrained to
distribute effort in the prescribed time frame.

Another view is that the rough chronological bounds have
been discussed by the developers and customers, but the enddate is best set by the developer after carefully considering
how to best use the resources needed to meet the customer's
needs.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 4
Scheduling Principles

compartmentalization— the product and process must be
decomposed into a manageable number of activities and tasks

interdependency—indicate task interrelationship
 Time allocation - every task has start and completion dates that
take the task interdependencies into account

effort validation—be sure resources are available

defined responsibilities— every scheduled task needs to be
assigned to a specific team member

defined outcomes—each task must have an output

defined milestones— a milestone is accomplished when one or
more work products from an engineering task have passed quality
review
SWE311_Ch24 (071)
Software & Software Engineering
Slide 5
Relationship Between People and Effort

Common myth:

Adding people to a project after it is behind schedule often causes the
schedule to slip further

The relationship between the number of people on a project
and overall productivity is not linear (e.g., 3 people do not
produce 3 times the work of 1 person, if the people have to
work in cooperation with one another)

The main reasons for using more than 1 person on a project are
to get the job done more rapidly and to improve software
quality.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 6
Effort and Delivery Time
Ef f ort
Cost
Ea = m ( t d 4 / t a 4 )
Imposs ible
region
Ea = ef f ort in pers on-months
t d = nominal deliv ery t ime f or s chedule
t o = optim al dev elopment time (in terms of c ost )
t a = ac tual deliv ery t ime des ired
Ed
Eo
td
to
dev elopment time
Tmin = 0.75T d
SWE311_Ch24 (071)
Software & Software Engineering
Slide 7
The project scheduling process
Identify
activities
Identify activity
dependencies
Estimate resources
for activities
Create project
char ts
Activity, bar, Gantt
Charts
Software
requirements
SWE311_Ch24 (071)
Allocate people
to activities
Software & Software Engineering
Slide 8
Effort Allocation
40-50%
15-20%

“front end” activities





construction activities


30-40%
SWE311_Ch24 (071)
customer communication
analysis
design
review and modification
coding or code generation
testing and installation



unit, integration
white-box, black box
regression
Software & Software Engineering
Slide 9
Project Effort Distribution


The 40-20-40 rule (a rule of thumb):

40% front-end analysis and design

20% coding

40% back-end testing
Generally accepted guidelines are:

02-03 % planning

10-25 % requirements analysis

20-25 % design

15-20 % coding
SWE311_Ch24 (071)
Software & Software Engineering
Slide 10
Software Project Types

Concept development - initiated to explore new business
concept or new application of technology

New application development - new product requested by
customer

Application enhancement - major modifications to function,
performance, or interfaces (observable to user)

Application maintenance - correcting, adapting, or extending
existing software (not immediately obvious to user)

Reengineering - rebuilding all (or part) of a legacy system
SWE311_Ch24 (071)
Software & Software Engineering
Slide 11
Factors Affecting Task Set

A task set is a collection of software engineering work tasks, milestones,
and work products that must be accomplished to complete a particular
project











Size of project
Number of potential users
Mission criticality
Application longevity
Requirement stability
Ease of customer/developer communication
Maturity of applicable technology
Performance constraints
Embedded/non-embedded characteristics
Project staffing
Reengineering factors
SWE311_Ch24 (071)
Software & Software Engineering
Slide 12
Defining Task Sets

Activity





Major work unit
Start date
End date
Consumes resources
Results in work products
(and milestones)
Phase 1
Project
Phase 2
Phase N
SWE311_Ch24 (071)
Step 1
Step 2
Step 1
Step 2
Activity 1
Activity 2
Activity 3
Activity 1
Activity 2
Task 1
Task 2
Task 3
Step 1
Step 2
Software & Software Engineering
Slide 13
Scheduling

Task networks (activity networks) are graphic representations that can be of
the task interdependencies and can help define a rough schedule for
particular project

Scheduling tools should be used to schedule any non-trivial project.

PERT (program evaluation and review technique) and CPM (critical path
method) are quantitative techniques that allow software planners to identify
the chain of dependent tasks in the project work breakdown structure that
determine the project duration time.

Timeline (Gantt) charts enable software planners to determine what tasks
will need to be conducted at a given point in time (based on estimates for
effort, start time, and duration for each task).

The best indicator of progress is the completion and successful review of a
defined software work product.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 14
Task durations and dependencies
SWE311_Ch24 (071)
Activity
Duration (days)
T1
8
T2
15
T3
15
T4
10
T5
10
T2, T4 (M2)
T6
5
T1, T2 (M3)
T7
20
T1 (M1)
T8
25
T4 (M5)
T9
15
T3, T6 (M4)
T10
15
T5, T7 (M7)
T11
7
T9 (M6)
T12
10
T11 (M8)
Software & Software Engineering
Dependencies
T1 (M1)
Slide 15
Activity network
8 day s
1 4 /7 /0 3
15 da y s
M1
T3
15 da y s
T9
T1
5 day s
4 /8/ 03
T6
M4
2 5 /7 /0 3
4 /7 /0 3
st ar t
M3
2 5 /8/ 03
M6
7 day s
2 0 day s
15 day s
T7
T2
25 /7 /0 3
10 da y s
M2
T4
T11
10 day s
M7
T5
5 /9/ 03
11 /8/ 03
T10
1 8 /7 /0 3
M8
15 da y s
10 da ys
T12
M5
2 5 day s
Fini sh
T8
19 /9/ 03
SWE311_Ch24 (071)
Software & Software Engineering
Slide 16
Activity timeline
4 /7
11 /7
18 /7
2 5 /7
1 /8
8 /8
1 5 /8
22 /8
2 9 /8
5 /9
12 /9
1 9 /9
Star t
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Fini sh
SWE311_Ch24 (071)
Software & Software Engineering
Slide 17
Staff allocation
4 /7
Fred
1 1 /7
18 /7
2 5 /7
1 /8
8 /8
15 /8
2 2 /8
2 9 /8
5 /9
1 2 /9
19 /9
T4
T8
T11
T12
Jan e
T1
T3
T9
Ann e
T2
T6
Ji m
Mary
SWE311_Ch24 (071)
T10
T7
T5
Software & Software Engineering
Slide 18
Use Automated Tools to
Derive a Timeline Chart
SWE311_Ch24 (071)
Software & Software Engineering
Slide 19
Schedule Tracking


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 (the diamonds shown in
Figure 24.3) have been accomplished by the scheduled date.

compare actual start-date to planned start-date for each project task
listed in the resource table (Figure 24.4).

meet informally with practitioners to obtain their subjective assessment
of progress to date and problems on the horizon.

use earned value analysis (Section 24.6) to assess progress
quantitatively.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 20
Progress on an OO Project-I


Technical milestone: OO analysis completed

All classes and the class hierarchy have been defined and reviewed.

Class attributes and operations associated with a class have been defined and
reviewed.

Class relationships (Chapter 8) have been established and reviewed.

A behavioral model (Chapter 8) has been created and reviewed.

Reusable classes have been noted.
Technical milestone: OO design completed

The set of subsystems (Chapter 9) has been defined and reviewed.

Classes are allocated to subsystems and reviewed.

Task allocation has been established and reviewed.

Responsibilities and collaborations (Chapter 9) have been identified.

Attributes and operations have been designed and reviewed.

The communication model has been created and reviewed.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 21
Progress on an OO Project-II


Technical milestone: OO programming completed

Each new class has been implemented in code from the design model.

Extracted classes (from a reuse library) have been implemented.

Prototype or increment has been built.
Technical milestone: OO testing

The correctness and completeness of OO analysis and design models has been
reviewed.

A class-responsibility-collaboration network (Chapter 8) has been developed and
reviewed.

Test cases are designed and class-level tests (Chapter 14) have been conducted for
each class.

Test cases are designed and cluster testing (Chapter 14) is completed and the classes
are integrated.

System level tests have been completed.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 22
Earned Value Analysis

“Earned Value Analysis” is:


a quantitative measure given to each task as a percent of project
completed so far
an industry standard way to:



measure a project’s progress
forecast its completion date and final cost, and
provide schedule and budget variances along the way


rather than rely on a gut feeling
By integrating three measurements, it provides consistent,
numerical indicators with which you can evaluate and compare
projects.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 23
What’s more Important?
SWE311_Ch24 (071)

Knowing where you are on schedule?

Knowing where you are on budget?

Knowing where you are on work
accomplished?
Software & Software Engineering
Slide 24
EVA Integrates All Three

It compares the PLANNED amount of work with
what has actually been COMPLETED, to determine
if COST , SCHEDULE, and WORK
ACCOMPLISHED are progressing as planned.

Work is “Earned” or credited as it is completed.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 25
Earned Value needed because...


Have an accurate estimate of project status
Provides an “Early Warning” signal for prompt corrective
action.

Bad news does not age well.

Still time to recover

Timely request for additional funds
SWE311_Ch24 (071)
Software & Software Engineering
Slide 26
Basic Earned Value Measures

BCWS - Budgeted Cost of Work Scheduled


ACWP - Actual Cost of Work Performed


Cost incurred to accomplish the work that has been done to date
BCWP - Budgeted Cost of Work Performed


Planned cost of the total amount of work scheduled to be performed by
the milestone date
The planned (not actual) cost to complete the work that has been done
BAC - Budget At Completion
SWE311_Ch24 (071)
Software & Software Engineering
Slide 27
Derived Earned Value Measures continued

SPI: Schedule Performance Index




CPI: Cost Performance Index



SPI = BCWP/BCWS
SPI < 1  project is behind schedule
The closer SPI to 1 indicates more efficient execution of project
CPI = BCWP/ACWP
CPI < 1  project is over budget
CSI: Cost Schedule Index


CSI = CPI x SPI
The further CSI is from 1.0, the less likely project recovery becomes.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 28
Derived Earned Value Measures

SV: Schedule Variance (BCWP-BCWS)
 A comparison of amount of work performed during a given
period of time to what was scheduled to be performed.
 A negative variance means the project is behind schedule

CV: Cost Variance (BCWP-ACWP)
 A comparison of the budgeted cost of work performed with
actual cost.
 A negative variance means the project is over budget.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 29
Derived Earned Value Measures

Percent scheduled for completion = BCWS/BAC


continued
provides an indication of the percentage of work that
should have been completed by time t.
Percent complete = BCWP/BAC

provides a quantitative indication of the percent of
completeness of the project at a given point in time, t.
SWE311_Ch24 (071)
Software & Software Engineering
Slide 30