Lecture 7
Project Scheduling and Tracking
1









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


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




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 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 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








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



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






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


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

◦ 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 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












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

Adaptation
Criteria
Step 2
Grade 1 to 5
Grade Weight
Conc Ndev
Entry Point Multiplier
Enhan Maint Reeng
Product
Size of project 1.20
0 1 1 1 1
Number of users
Business criticality
Longevity
Stability of requirements
Ease of communication
Maturity of technology
Step 3
Weight 0.8 – 1.2
Performance constraints
Embedded/nonembed ded
0.90
0.80
1.20
1.10
1.10
0.90
1.20
0.90
0
1
1
1
0
0
0
0
1
1
1
1
1
1
1
1
Step 1
0
1
0
1
1
1
1
1 1 1 1
Step 4
1 Grade x weight x entry point multiplier
1 1 0 1
1 1
Step 5
0
TSS = Average(Products)
1
14

Task Set Selector Value Degree of rigor
TSS < 1.2
Casual
1.0 < TSS < 3.0
Structured
TSS > 2.4
Strict
15



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


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



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







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



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




BCWS (Budgeted cost of work scheduled) is the sum of the BCWS i 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 =  (BCWS all tasks k k
) for
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






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




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


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


Pressman, Chapter 7
25