Software Engineering Lecture 7: Scheduling & Tracking

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

Why is Software Late? l Unrealistic deadline (external) l Changing requirements not reflected in the schedule l Honest underestimation l 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 the deadline 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 l Perform detailed estimate based on past data l Develop an incremental model that delivers critical functionality by original deadline l Explain estimate to the customer l Offer incremental alternative

Why Do Plans Fail? l “None love the bearer of bad news” (Sophocles) Don’t postpone making adjustments to a project in trouble! l 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 l Macroscopic schedule early; identify major activities, milestones l Detailed schedule project underway; specific tasks identified and scheduled l Schedule drivers: fixed delivery date (resources flexible) fixed resources (dates flexible)

Scheduling Principles l Compartmentalization product and process decomposition improves manageability l Interdependency identify hard constraints on task scheduling l Time allocation effort level, start/end dates

Scheduling Principles [2] l Effort validation resource loading varies day to day; are there any unrealistic “peaks”? l Defined responsibilities tasks assigned to individuals l Defined outcomes tasks have specific work products l Defined milestones review for quality, “approval”

Time vs. Effort l A non-linear relationship l Communication overhead increases with more people l 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 l 40% Analysis and Design l 20% Implementation l 40% Testing and Evaluation l Disparity between design and implementation grows with complexity

Types of Software Projects l Concept development l New application development l Application enhancement l Application maintenance l Reengineering Each type might use a different life-cycle model, task sets, teaming arrangements, etc.

Degree of Rigor l Casual, Structured, Strict Increasing level of attention to formal task sets, umbrella activities, etc. l Quick Reaction Only tasks related to maintaining quality are applied; additional detail (documentation, etc.) added later

[From SEPA 5/e] Concept Development, Linear Sequential Model

[From SEPA 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 l Task Dependencies, Critical Path Task Network (macro level) PERT chart (micro level) l Task Concurrency, Resources Gannt chart (timeline chart)

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

PERT [2] l Consider: Earliest start, latest start, earliest finish, latest finish l Derive critical path, insert milestones l Assign resources

Gantt Chart l “Timeline” view of project l Different perspective Shows parallel activities more clearly Shows resource overload more clearly Doesn’t show dependencies as clearly

[From SEPA 5/e]

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

Resource Graphs l Percent allocation per employee per day l Expose overflow/underflow l Global view of resources over project lifetime Ramp-up Ramp-down

Calendar View l Include tasks and employees l Best for weekly tracking l Easiest view for individuals focusing on their own tasks

Tracking and Control l Periodic status meetings Evaluate results of reviews Determine if milestones are met Compare actual start to planned start for each task l 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 l Carry two sets of dates in the schedule l Constant variance in “estimated” times l “Scheduled” times change only when necessary l “Under-promise, over-deliver”

Planning Lessons l A plan is only useful if it is tracked regularly and updated when necessary l Bad news is better in small, early increments

Scheduling: Summary l Estimation + Risk Analysis + Scheduling = Project Plan l Begins with decomposition l Task network created l Time line, Critical path, Resource allocation l Basis for Tracking and Control

Questions?