chapter 24 project scheduling and tracking

SWE311_Ch24 (071) Software & Software Engineering Slide 1

Chapter 24Chapter 24Project Scheduling and TrackingProject Scheduling and Tracking


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 groupsoftware development group changing customer requirements that are not reflected in changing customer requirements that are not reflected in

schedule changes;schedule changes; 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; 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 problemproblem


How to Deal With Unrealistic How to Deal With Unrealistic Schedule DemandsSchedule Demands

Perform a detailed project estimate for project Perform a detailed project estimate for project effort and duration using historical data. effort and duration using historical data.

Use an incremental process model that will Use an incremental process model that will deliver critical functionality imposed by deadline, deliver critical functionality imposed by deadline, but delay other requested functionality. but delay other requested functionality.

Meet with the customer and explain why the Meet with the customer and explain why the deadline is unrealistic using your estimates based deadline is unrealistic using your estimates based on prior team performance. on prior team performance.

Offer an incremental development and delivery Offer an incremental development and delivery strategy as an alternative to increasing resources strategy as an alternative to increasing resources or allowing the schedule to slip beyond the or allowing the schedule to slip beyond the deadline. deadline.


Project Scheduling PerspectivesProject Scheduling Perspectives

One view is that the end-date for the software release is set One view is that the end-date for the software release is set externally and that the software organization is constrained to externally and that the software organization is constrained to distribute effort in the prescribed time frame. distribute effort in the prescribed time frame.

Another view is that the rough chronological bounds have Another view is that the rough chronological bounds have been discussed by the developers and customers, but the end-been discussed by the developers and customers, but the end-date is best set by the developer after carefully considering date is best set by the developer after carefully considering how to best use the resources needed to meet the customer's how to best use the resources needed to meet the customer's needs.needs.


Scheduling PrinciplesScheduling Principles compartmentalizationcompartmentalization— the product and process must be — the product and process must be

decomposed into a manageable number of activities and tasks decomposed into a manageable number of activities and tasks

interdependencyinterdependency—indicate task interrelationship —indicate task interrelationship

Time allocationTime allocation - every task has start and completion dates that - every task has start and completion dates that take the task interdependencies into account take the task interdependencies into account

effort validationeffort validation—be sure resources are available—be sure resources are available

defined responsibilitiesdefined responsibilities— every scheduled task needs to be — every scheduled task needs to be assigned to a specific team member assigned to a specific team member

defined outcomesdefined outcomes—each task must have an output—each task must have an output

defined milestonesdefined milestones— a milestone is accomplished when one or — a milestone is accomplished when one or more work products from an engineering task have passed quality more work products from an engineering task have passed quality review review


Relationship Between People and EffortRelationship Between People and Effort

Common myth: Adding people to a project after it is behind schedule often causes the Adding people to a project after it is behind schedule often causes the

schedule to slip further schedule to slip further

The relationship between the number of people on a project The relationship between the number of people on a project and overall productivity is not linear (e.g., 3 people do not 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 produce 3 times the work of 1 person, if the people have to work in cooperation with one another) work in cooperation with one another)

The main reasons for using more than 1 person on a project The main reasons for using more than 1 person on a project are to get the job done more rapidly and to improve software are to get the job done more rapidly and to improve software quality.quality.


Effort and Delivery TimeEffort and Delivery Time

Effort Cost

Impossible region

td

Ed

Tmin = 0.75T d

to

Eo

Ea = m (td4/ ta

4)

development time

Ea = effort in person-months

td = nominal delivery time for schedule

to = optimal development time (in terms of cost)

ta = actual delivery time desired


The project scheduling processThe project scheduling process

Estimate resourcesfor activities

Identify activitydependencies

Identifyactivities

Allocate peopleto activities

Softwarerequirements

Create projectcharts

Activity, bar, Gantt Charts


Effort AllocationEffort Allocation

40-50%40-50%

30-40%30-40%

““front end” activitiesfront end” activities customer communicationcustomer communication analysisanalysis designdesign review and modificationreview and modification

construction activitiesconstruction activities coding or code coding or code

generationgeneration testing and installationtesting and installation

unit, integrationunit, integration white-box, black boxwhite-box, black box regression regression

15-20%15-20%


Project Effort DistributionProject Effort Distribution The 40-20-40 rule (a rule of thumb): The 40-20-40 rule (a rule of thumb):

40% front-end analysis and design 40% front-end analysis and design

20% coding 20% coding

40% back-end testing40% back-end testing

Generally accepted guidelines are: Generally accepted guidelines are: 02-03 % planning 02-03 % planning

10-25 % requirements analysis 10-25 % requirements analysis

20-25 % design 20-25 % design

15-20 % coding 15-20 % coding


Software Project TypesSoftware Project Types Concept development - initiated to explore new business Concept development - initiated to explore new business

concept or new application of technology concept or new application of technology

New application development - new product requested by New application development - new product requested by customer customer

Application enhancement - major modifications to function, Application enhancement - major modifications to function, performance, or interfaces (observable to user) performance, or interfaces (observable to user)

Application maintenance - correcting, adapting, or extending Application maintenance - correcting, adapting, or extending existing software (not immediately obvious to user) existing software (not immediately obvious to user)

Reengineering - rebuilding all (or part) of a legacy systemReengineering - rebuilding all (or part) of a legacy system


Factors Affecting Task SetFactors Affecting Task Set A task set is a collection of software engineering work tasks, milestones, A task set is a collection of software engineering work tasks, milestones,

and work products that must be accomplished to complete a particular and work products that must be accomplished to complete a particular projectproject Size of project Size of project Number of potential users Number of potential users Mission criticality Mission criticality Application longevity Application longevity Requirement stability Requirement stability Ease of customer/developer communication Ease of customer/developer communication Maturity of applicable technology Maturity of applicable technology Performance constraints Performance constraints Embedded/non-embedded characteristics Embedded/non-embedded characteristics Project staffing Project staffing Reengineering factorsReengineering factors


Defining Task SetsDefining Task Sets

ActivityActivity Major work unitMajor work unit Start date Start date End dateEnd date Consumes resourcesConsumes resources Results in work products Results in work products

(and milestones)(and milestones)

Project

Phase 1

Phase 2

Phase N

Step 1

Step 2

Step 1

Step 2

Step 1

Step 2

Activity 1Activity 2Activity 3

Activity 1Activity 2 Task 1

Task 2Task 3


SchedulingScheduling Task networks (activity networks) are graphic representations that can be Task networks (activity networks) are graphic representations that can be

of the task interdependencies and can help define a rough schedule for of the task interdependencies and can help define a rough schedule for particular project particular project

Scheduling tools should be used to schedule any non-trivial project. Scheduling tools should be used to schedule any non-trivial project.

PERT (program evaluation and review technique) and CPM (critical path PERT (program evaluation and review technique) and CPM (critical path method) are quantitative techniques that allow software planners to method) are quantitative techniques that allow software planners to identify the chain of dependent tasks in the project work breakdown identify the chain of dependent tasks in the project work breakdown structure that determine the project duration time. structure that determine the project duration time.

Timeline (Gantt) charts enable software planners to determine what tasks 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 will need to be conducted at a given point in time (based on estimates for effort, start time, and duration for each task). effort, start time, and duration for each task).

The best indicator of progress is the completion and successful review of a The best indicator of progress is the completion and successful review of a defined software work product. defined software work product.


Task durations and dependenciesTask durations and dependencies

Activity Duration (days) Dependencies

T1 8

T2 15

T3 15 T1 (M1)

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)


Activity networkActivity network

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/03

8 days

14/7/03 15 days

4/8/03

15 days

25/8/03

7 days

5/9/03

10 days

19/9/03

15 days

11/8/03

25 days

10 days

20 days

5 days25/7/03

15 days

25/7/03

18/7/03

10 days

T1

M1 T3T9

M6

T11

M8

T12

M4


Activity timelineActivity timeline4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T1T2

M1

T7T3

M5

T8

M3

M2

T6

T5

M4

T9

M7

T10

M6

T11M8

T12

Start

Finish


Staff allocationStaff allocation4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T8 T11

T12

T1

T3

T9

T2

T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim


Use Automated Use Automated Tools toTools to

Derive a Timeline Derive a Timeline ChartChart

I.1.1 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement definedI.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 definedI.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 completeI.1.4 Isolate software elements Milestone: Software elements definedI.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 identifiedI.1.6 Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessedI.1.7 Make quick estimate of sizeI.1.8 Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete

week 1 week 2 week 3 week 4Work tasks week 5


Schedule TrackingSchedule Tracking conduct periodic project status meetings in which each team member conduct periodic project status meetings in which each team member

reports progress and problems.reports progress and problems. evaluate the results of all reviews conducted throughout the software evaluate the results of all reviews conducted throughout the software

engineering process.engineering process. determine whether formal project milestones (the diamonds shown in determine whether formal project milestones (the diamonds shown in

Figure 24.3) have been accomplished by the scheduled date.Figure 24.3) have been accomplished by the scheduled date. compare actual start-date to planned start-date for each project task compare actual start-date to planned start-date for each project task

listed in the resource table (Figure 24.4).listed in the resource table (Figure 24.4). meet informally with practitioners to obtain their subjective assessment meet informally with practitioners to obtain their subjective assessment

of progress to date and problems on the horizon.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-IProgress on an OO Project-I 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 and Class attributes and operations associated with a class have been defined and

reviewed.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 completedTechnical 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 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. Attributes and operations have been designed and reviewed.Attributes and operations have been designed and reviewed. The communication model has been created and reviewed.The communication model has been created and reviewed.


Progress on an OO Project-IIProgress on an OO Project-II Technical milestone: OO programming completedTechnical 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 testingTechnical milestone: OO testing The correctness and completeness of OO analysis and design models has been The correctness and completeness of OO analysis and design models has been

reviewed.reviewed. A class-responsibility-collaboration network (Chapter 8) has been developed and A class-responsibility-collaboration network (Chapter 8) has been developed and

reviewed.reviewed. Test cases are designed and class-level tests (Chapter 14) have been conducted for Test cases are designed and class-level tests (Chapter 14) have been conducted for

each class.each class. Test cases are designed and cluster testing (Chapter 14) is completed and the classes Test cases are designed and cluster testing (Chapter 14) is completed and the classes

are integrated.are integrated. System level tests have been completed.System level tests have been completed.


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.


What’s more Important?What’s more Important? Knowing where you are on schedule?Knowing where you are on schedule?

Knowing where you are on budget?Knowing where you are on budget?

Knowing where you are on work Knowing where you are on work accomplished?accomplished?


EVA Integrates All ThreeEVA Integrates All Three

It compares the PLANNED amount of work with It compares the PLANNED amount of work with what has actually been COMPLETED, to determine what has actually been COMPLETED, to determine if if COSTCOST , , SCHEDULESCHEDULE, and, and WORKWORK ACCOMPLISHEDACCOMPLISHED are progressing as planned. are progressing as planned.

Work is “Earned” or credited as it is completedWork is “Earned” or credited as it is completed ..


Earned Value needed because...Earned Value needed because...

Have an accurate estimate of project statusHave an accurate estimate of project status Provides an “Early Warning” signal for prompt corrective Provides an “Early Warning” signal for prompt corrective

action.action.

Bad news does not age well.Bad news does not age well.

Still time to recoverStill time to recover

Timely request for additional fundsTimely request for additional funds


Basic Earned ValueEarned Value Measures

BCWS - Budgeted Cost of Work Scheduled Planned cost of the total amount of work scheduled to be performed by

the milestone date

ACWP - Actual Cost of Work Performed Cost incurred to accomplish the work that has been done to date

BCWP - Budgeted Cost of Work Performed The planned (not actual) cost to complete the work that has been done

BAC -BAC - Budget At CompletionBudget At Completion


Derived Earned ValueEarned Value Measures continued

SPI: Schedule Performance IndexSPI: Schedule Performance Index SPI = BCWP/BCWSSPI = BCWP/BCWS SPI < 1 SPI < 1 project is behind schedule project is behind schedule The closer SPI to 1 indicates more efficient execution of projectThe closer SPI to 1 indicates more efficient execution of project

CPI: Cost Performance IndexCPI: Cost Performance Index CPI = BCWP/ACWPCPI = BCWP/ACWP CPI < 1 CPI < 1 project is over budget project is over budget

CSI: Cost Schedule Index CSI: Cost Schedule Index CSI = CPI x SPICSI = CPI x SPI The further CSI is from 1.0, the less likely project recovery becomes.The further CSI is from 1.0, the less likely project recovery becomes.


Derived Earned ValueEarned Value Measures

SV: Schedule Variance (BCWP-BCWS)SV: Schedule Variance (BCWP-BCWS) A comparison of amount of work performed during a given A comparison of amount of work performed during a given

period of time to what was scheduled to be performed.period of time to what was scheduled to be performed. A negative variance means the project is behind scheduleA negative variance means the project is behind schedule

CV: Cost Variance (BCWP-ACWP)CV: Cost Variance (BCWP-ACWP) A comparison of the budgeted cost of work performed with A comparison of the budgeted cost of work performed with

actual cost.actual cost. A negative variance means the project is over budget.A negative variance means the project is over budget.


Derived Earned ValueEarned Value Measures continued

Percent scheduled for completion = BCWS/BACPercent scheduled for completion = BCWS/BAC

provides an indication of the percentage of work that provides an indication of the percentage of work that should have been completed by time should have been completed by time t.t.

Percent complete = BCWP/BACPercent complete = BCWP/BAC

provides a quantitative indication of the percent of provides a quantitative indication of the percent of completeness of the project at a given point in time, completeness of the project at a given point in time, t.t.

chapter 24 project scheduling and tracking

Documents

project effort distribution

project staff

project management

detailed project estimate

effort andor

number of people

task interdependencies

outcomeseach task