These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, Software Engineering: A Practitioner’s Approach, 6/e Chapter 24 Project Scheduling Software Engineering: A Practitioner’s Approach, 6/e Chapter 24 Project Scheduling copyright © 1996, 2001, 2005 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.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/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 an unrealistic deadline established by someone outside the software development group changing customer requirements that are not reflected in schedule changes; 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; 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; predictable and/or unpredictable risks that were not considered when the project commenced;

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, Why Are Projects Late(Cont.)? technical difficulties that could not have been foreseen in advance; technical difficulties that could not have been foreseen in 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 falling behind schedule and a lack of action to correct the problem a failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, What To Do If Deadline Is Unrealistic Perform a detailed estimate using historical data from past projects. Determine the estimated effort and duration for the project Perform a detailed estimate using historical data from past projects. Determine the estimated effort and duration for the project Using an incremental process model, develop a software engineering strategy that will deliver critical functionality by the imposed deadline, but delay other functionality until late. Document the plan Using an incremental process model, develop a software engineering strategy that will deliver critical functionality by the imposed deadline, but delay other functionality until late. Document the plan Meet with the customer, explain why the imposed deadline is unrealistic. Be certain to note that all estimates are based on performance on past projects and indicate the percent improvement that would be required to achieve the deadline Meet with the customer, explain why the imposed deadline is unrealistic. Be certain to note that all estimates are based on performance on past projects and indicate the percent improvement that would be required to achieve the deadline Offer the incremental development strategy as alternative Offer the incremental development strategy as alternative

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, Scheduling Principles Compartmentalization—define distinct tasks Compartmentalization—define distinct tasks Interdependency—indicate task interrelationships Interdependency—indicate task interrelationships Time allocation—define time interval Time allocation—define time interval Effort validation—be sure resources are available Effort validation—be sure resources are available Defined responsibilities—people must be assigned Defined responsibilities—people must be assigned Defined outcomes—each task must have an output Defined outcomes—each task must have an output Defined milestones—review for quality Defined milestones—review for quality

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, Defining Task Sets Determine type of project Determine type of project  Concept development projects  New application development projects  Application enhancement projects  Application maintenance projects  Reegineering projects Assess the degree of rigor required 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 Select appropriate software engineering tasks

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, Define a Task Network Three I.5 tasks are applied in parallel to 3 different concept functions Three I.3 tasks are applied in parallel to 3 different concept functions

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

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