1. 1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2. 2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 7 Project Scheduling and Tracking

3. 3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Why Are Projects Late?  an unrealistic deadline established by someone outside the software development group  changing customer requirements that are not reflected in schedule changes;  an honest underestimate of the amount of effort and/or the number of resources that will be required to do the job;  predictable and/or unpredictable risks that were not considered when the project commenced;  technical 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;  a failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem

4. 4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Scheduling Principles  compartmentalization—define distinct tasks  interdependency—indicate task interrelationshipsffort validation—be sure resources are available  defined responsibilities—people must be assigned  defined outcomes—each task must have an output  defined milestones—review for quality

5. 5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Defining Task Sets  determine type of project  assess the degree of rigor required  identify adaptation criteria  compute task set selector (TSS) value  interpret TSS to determine degree of rigor  select appropriate software engineering tasks

6. 6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Example

7. 7 Define a Task Network

8. 8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Effort Allocation 40-50% 30-40%  “front end” activities  customer communication  analysis  design  review and modification  construction activities  coding or code generation  testing and installation  unit, integration  white-box, black box  regression 15-20%

9. 9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Use Automated Tools to Derive a Timeline Chart