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 Meeting the Deadline  The customer has a deadline of 9 months to release a new medical diagnositc instrument.  Based on previous experience, you predict the software for it will take 14 months to complete.  What do you do?

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 Recommended Steps:  Perform detailed estimate based on historical data.  Use an incremental process and develop a plan that will deliver critical functions in 9 months, but others in 14 months.  Meet with the customer and explain why the deadline is too tight.  Suggest options to the customer…

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 Suggest Options to the Customer:  Deliver critical functions in 9 months, the rest in 14 months  Add resources and try to complete in 9 months. The tight deadline might mean less quality.  Keep 9 month deadline as is, knowing it will probably not be met.

7. 7 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  Fred Brooks  The Mythical Man Month  Software projects fall behind "One day at a time."

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  Identify tasks to break project into small parts.  Identify critical path and tasks on the critical path.  If the critical path tasks ffall behind, the project will be late.

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 Task Breakdown  macroscopic schedule - big picture  detailed schedule - made for each task on the macroscopic schedule

10. 10 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

11. 11 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 Adding People to a Project  3 people = 3 interfaces  4 people = 3+2+1 = 6 interfaces  6 people = 5+4+3+2+1 = 15 interfaces

12. 12 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 Project Size vs. Resources  Project resources required increase faster than the project size increases. (not linear)

13. 13 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 Distribution  40-20-40 rule  40% analysis and design  20% coding  40% testing  This is only a guideline. Each project is different.  Only about 30% of all work is new development, the other 70% is maintenance.

14. 14 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  Adapt the process based on Adaptation criteria. See page 174  Computing task set selector. See page 175

15. 15 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

16. 16 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 Selecting Software Engineering Tasks  Scoping  Preliminary Planning  Technology Risk Assessment  Proof of Concept  Concept Implementation  Customer Reaction to the Concept

17. 17 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 Refinement of Tasks  See page 179-180

18. 18 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

19. 19 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 Define a Task Network

20. 20 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%

21. 21 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  PERT - Program Evaluation and Review Technique  CPM - Critical Path Method  WBS - Work Breakdown Structure

22. 22 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 Common Features  Estimates of effort  A decomposition of the product function  The selection of the appropriate process model and task set  Decomposition of tasks

23. 23 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 Gantt Chart  Also called Timeline Chart  Decide on tasks - WBS  Estimate time for each task  Assign personnel to each task  Determine dependencies  Which can be done in parallel?  Make Gantt Chart  Set milestones  Set start and end dates for tasks  See page 183 and 184

24. 24 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

25. 25 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 Tracking the Schedule  Ways to track:  Conduct periodic project status meetings  Evaluate results of all reviews  Check milestones  Compare actual start/end dates of tasks to estimates.  Meet informally with supervisors to obtain their assessment of progress.

26. 26 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 Error Tracking  Record errors found in reviews.  Record errors you find yourself.

27. 27 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 Earned Value Analysis  BCWS - budgeted cost of word scheduled  estimate for each task  BAC - budget at completion  BAC = (BCWSk) for all tasks k  BCWP - Budgeted cost of work performed  BCWP = (BCWSk) for tasks already performed  BCWS - budgeted cost of work scheduled to be completed by a given date  cont.

28. 28 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  SPI - schedule performance index  SPI = BCWP / BCWS (to a given time)  SPI = 1.0 is good  SPI = 0.5 means only 50% of work scheduled to date has been completed.  Percent scheduled for completion to date  = BCWS / BAC  Percent actually completed to date  = BCWP / BAC