Transcript Project Scheduling and Tracking

Software Engineering
Lecture 7
Project Scheduling and Tracking
1
Why software is delivered late
Unrealistic deadline
 Changing Customer Requirements
 Underestimate of the amount of effort
 Predictable / Unpredictable risks
 Technical Difficulties
 Human Difficulties
 Miscommunication among project staff
 Lack of action to overcome the lateness

2
Comments on “Lateness”

It is unrealistic to march into the
customer’s office and demand that the
delivery date be changed, because:
◦ External market pressures have dictated the
date, and the product must be released
◦ Developers cannot refuse to undertake the
work (from a career standpoint)
3
Recommended solutions
Perform a detailed estimate using
historical data from past projects
 Using an incremental process model
(deliver critical functionality, delay others)
 Meet with the customer and explain why
the imposed deadline is unrealistic (using
the detailed estimate)

4
Project Scheduling Basic Principles

Project Manager’s Objectives:
◦ Define all project tasks
◦ Build a network of task interdependencies
◦ Identify tasks that lie on the critical path
Software Project Scheduling is an activity
that distributes estimated effort across
the planned project duration by allocating
the effort to specific software engineering
tasks.
 The schedule evolves over time.

5
Macroscopic vs Detailed Schedule
Macroscopic schedule: identifies all major
software engineering activities and the
product functions to which they are
applied
 As the project gets under way, each entry
on the macroscopic schedule is refined
into a detailed schedule.
 Detailed schedule: specific software tasks
(required to acomplish an activity) are
identified and scheduled

6
Software Project Scheduling Guidelines
Compartmentalization (decompose activities
and tasks)
 Interdependency (of activities / tasks)
 Time Allocation (for each task)
 Effort Validation (e.g. 3 person-day for a task)
 Defined Responsibilities (task - team
member assignment)
 Defined Outcomes (e.g. work product)
 Defined Milestones (a group of approved
work products)

7
Defining a task set for the software
project
A task set is a collection of software
engineering work tasks, milestones, and
deliverables that must be accomplished to
complete a particular project
 Task sets are designed to accommodate
different types of projects and different
degrees of rigor

8
Taxonomy of software project types
Concept development projects (explore
new business concepts / new technology)
 New application development projects
 Application enhancement projects (major
modifications to functions, performance,
or interfaces)
 Application maintenance projects
(correct, adapt, or extend existing
software)
 Reengineering projects (rebuild an
existing system)

9
Degree of rigor (1)

The degree of rigor is a function of many
project characteristics.
◦ Casual




All process framework activities are applied
A minimum task set is required
Umbrella tasks are minimized
Documentation requirements are reduced.
◦ Structured
 All process framework activities are applied
 SQA, SCM, documentation, and measurement tasks
will be conducted in a streamlined manner
10
Degree of rigor (2)
◦ Strict
 The full process will be applied with a degree of
discipline to ensure high quality
 All umbrella activities will be applied
 Robust work products will be produced
◦ Quick Reaction
 The process framework will be applied, but only
those tasks essential to maintaining good quality will
be applied
 Back-filing (documentation, reviews) will be
accomplished after the product is delivered
11
Adaptation Criteria





Adaptation criteria are used to determine the
recommended degree of rigor with which the software
process should be applied on a project.
Evelen adaptation criteria are defined for a software project.
Each of the adaptation criteria is assigned a grade that
ranges between 1 and 5.
1 represents a small set of process tasks are required
(minimal requirements)
5 represents a complete set of process tasks should be
applied (overall methodological and documentation)
12
Eleven adaptation criteria
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 constrains
 Embedded and nonembedded characteristics
 Project staff
 Reengineering factors

13
Computing The Task Set Selector
Adaptation
Criteria
Step 2
Grade 1 to 5
Grade
Weight
Entry Point Multiplier
Product
Conc
Ndev
Enhan
Maint
Reeng
Size of project
1.20
0
1
1
1
1
Number of users
1.10
0
1
1
1
1
Business criticality
1.10
0
1
1
1
1
Step 1
1
0
Choose
the0project type
Longevity
0.90
0
1
Stability of
requirements
1.20
0
1
1
1
1
Ease of communication
0.90
1
1
1
1
1
Maturity of technology
0.90
1
Step 4
1Grade x weight
0
0
x entry
point1 multiplier
Performance
constraints
0.80
0
1
Embedded/nonembed
ded
1.20
1
1
Step 3
Weight 0.8 – 1.2
1
0
Step 5
0
TSS = Average(Products)
1
1
1
14
Interpreting the TSS value
Task Set Selector Value
Degree of rigor
TSS < 1.2
Casual
1.0 < TSS < 3.0
Structured
TSS > 2.4
Strict
15
Project Scheduling Methods (1)
PERT (Program Evaluation and Review
Technique) and CPM (Critical Path
Method) are two project scheduling
methods that can be applied to software
development.
 Interdependencies among tasks may be
defined using a task network (activity
network), a graphic representation of the
task flow for a project.

16
Project Scheduling Methods (2)

Both PERT and CPM provide quantitative
tools that allow the software planner to:
◦ Determine the critical path
◦ Establish “most likely” time estimates for
individual tasks
◦ Calculate “boundary times” that define a time
“window” for a particular task
17
Timeline Charts
A timeline chart, also called a Gantt chart
depicts the software project schedule for
the entire project.
 Alternatively, separate charts can be
developed for each project function or
for each individual working on the
project.

18
Tracking the Schedule






Conducting periodic project status meeting
Evaluating the results of all conducted reviews
Determining whether milestones have been
accomplished by the scheduled date
Comparing actual start-date to planned start-date
for each project task
Meeting informally with practitioners to obtain
their subjective assessment of progress to date
Using Earned Value Analysis to assess progress
quantitatively
19
Earned Value Analysis (1)
The earned value analysis (Humphrey,
1995) provides a common value scale for
every software project 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.
 Earned value is simply a measure of
progress.

20
Earned Value Analysis (2)



BCWS (Budgeted cost of work scheduled) 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.
The BCWS values for all work tasks are
summed to derive the Budget At
Completion (BAC). BAC = (BCWSk) for
all tasks k
BCWP (Budgeted cost of work performed)
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.
21
Earned Value Analysis (3)

Given values for BCWS, BAC, and BCWP,
important progress indicators can be
computed:

Schedule Performance Index, an indication of the efficiency
with which the project is utilizing scheduled resources. SPI =
BCWP / BCWS
Schedule Variance, an absolute indication of variance from the
planned schedule. SV = BCWP – BCWS
Percent scheduled for completion = BCWS / BAC
Percent complete = BCWP / BAC



22
Earned Value Analysis (4)
ACWP (Actual cost of work performed) is the sum of
the effort actually expended on work tasks that have
been completed by a point in time on the project
schedule.
 Cost performance index, CPI = BCWP / ACWP
 Cost variance, CV = BCWP – ACWP

23
Summary

Scheduling is the culmination of a planning
activity that is a primary component of
software project management. When
combined with estimation methods and
risk analysis, scheduling establishes a road
map for the project manager.
24
References

Pressman, Chapter 7
25