Software Engineering

Lecture 7: Scheduling & Tracking

Today’s Topics Why is Scheduling Hard? Scheduling Principles Time vs. Effort Scheduling Methods Tracking & Control

Why is Software Late?

Unrealistic deadline (external) Changing requirements not reflected in the

schedule Honest underestimation Risks not considered...

• Unforeseen technical difficulties

• Human difficulties

• Miscommunication

• Management failure

Quotes “Any commander-in-chief who

undertakes to carry out a plan which he considers defective is at fault; he must put forth his reasons, insist on the plan being changed, and finally tender his resignation rather than be the instrument of his army’s downfall.”

[Napoleon Bonaparte]

Quotes [2]

If best estimates indicate that thedeadline is unrealistic, the manager should “protect his or her team from undue (schedule) pressure and reflect the pressure back to its originators”

[Page-Jones, 1985]

Coping with Unrealistic Deadlines

Perform detailed estimate based on past data Develop an incremental model that delivers

critical functionality by original deadline Explain estimate to the customer Offer incremental alternative

Why Do Plans Fail? “None love the bearer of bad news”

(Sophocles)Don’t postpone making adjustments to a project in trouble!

Q: “How does a project get to be a year late?” A: “One day at a time.”Any delay on the critical path can have a big impact!

[from Brooks, 1995]

Scheduling Levels

Macroscopic schedule• early; identify major activities, milestones

Detailed schedule• project underway; specific tasks identified and scheduled

Schedule drivers:• fixed delivery date (resources flexible)

• fixed resources (dates flexible)

Scheduling Principles

Compartmentalization• product and process decomposition

• improves manageability

Interdependency• identify hard constraints on task scheduling

Time allocation• effort level, start/end dates

Scheduling Principles [2]

Effort validation• resource loading varies day to day; are there any unrealistic

“peaks”?

Defined responsibilities• tasks assigned to individuals

Defined outcomes• tasks have specific work products

Defined milestones• review for quality, “approval”

Time vs. Effort A non-linear relationship Communication overhead increases with more

people E = LOC^3/(P^3*t^4)

• 12 person-years, 33K LOC

• 8 people = 1.3 years to completion

• 4 people = 1.75 years to completion

• 6-month extension halves resources

• P must be tracked historically...

[Putnam, 1992]

Effort Distribution

40% Analysis and Design 20% Implementation 40% Testing and Evaluation Disparity between design and implementation

grows with complexity

Types of Software Projects Concept development New application development Application enhancement Application maintenance Reengineering

Each type might use a different life-cycle model, task sets, teaming arrangements, etc.

Degree of Rigor Casual, Structured, Strict

• Increasing level of attention to formal task sets, umbrella activities, etc.

Quick Reaction• Only tasks related to maintaining quality are applied; additional

detail (documentation, etc.) added later

[Fro

m S

EPA

5/e

]

Concept Development, Linear Sequential Model

[Fro

m S

EPA

5/e

]

Concept Development, Linear Sequential Model

[From SEPA 5/e]

Task Network, Macroscopic Level

Q: Is there a critical path?A: Can’t tell until we add scheduling detail! (microscopic level)

Scheduling Methods Task Dependencies, Critical Path

• Task Network (macro level)

• PERT chart (micro level)

Task Concurrency, Resources• Gannt chart (timeline chart)

PERT Chart

Program Evaluation and Review Technique Identify task dependencies Order tasks chronologically Link tasks in a network diagram

PERT [2] Consider: Earliest start, latest start, earliest finish,

latest finish Derive critical path, insert milestones Assign resources

Gantt Chart

“Timeline” view of project Different perspective

• Shows parallel activities more clearly

• Shows resource overload more clearly

• Doesn’t show dependencies as clearly

[Fro

m S

EPA

5/e

]

Milestones

Make them concrete and crisp Best plan is one where “developers can’t deceive

themselves”

Resource Graphs

Percent allocation per employee per day Expose overflow/underflow Global view of resources over project lifetime

• Ramp-up

• Ramp-down

Calendar View

Include tasks and employees Best for weekly tracking Easiest view for individuals focusing on their

own tasks

Tracking and Control Periodic status meetings

• Evaluate results of reviews

• Determine if milestones are met

• Compare actual start to planned start for each task

Informal meetings with developers• Discuss individual challenges, time management techniques

• Another channel for “early warning”

[From SEPA 5/e]

An Example Project Table

Scheduled vs. Estimated

Carry two sets of dates in the schedule Constant variance in “estimated” times “Scheduled” times change only when necessary “Under-promise, over-deliver”

Planning Lessons

A plan is only useful if it is tracked regularly and updated when necessary

Bad news is better in small, early increments

Scheduling: Summary

Estimation + Risk Analysis + Scheduling = Project Plan

Begins with decomposition Task network created Time line, Critical path, Resource allocation Basis for Tracking and Control

Questions?