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 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 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 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 interrelationships  Time allocation – work unit (eg. Person-days of effort) or start-finish date for each task  Effort 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 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 People – Effort Relationship  The relationship between the number of people and productivity is not linear  Example: 4 software engineer, each capable of producing 5000 LOC/year Assume that each communication will reduce the productivity by 250 LOC/year Therefore, the number of communication path: 4!/(2!2!) = 6 team productivity: 5000*4 – 250*6 = 18,500 LOC/year ++

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 People – Effort Relationship (2)  Example 2: With 2 months remaining, 2 additional people are added Therefore, the number of communication path: 6!/(2!4!) = 15 productivity of 2 new staffs = 2 * (5000/12 month) * 2 month = 1680 LOC team productivity: 20, – 250*15  less than 18,500 LOC/year ++

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 Defining Task Sets  determine type of project Concept development New Application development Application enhancement Application maintenance Reengineering  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 A collection of software engineering work tasks, milestones, and deliverables

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 Degree of rigor  Adaptation Criteria  Size of the project  Number of potential users  Mission criticality  Application longevity  Stability of requirements  Ease of customer/developer communication  Maturity of applicable technology  Performance constraints  Embedded and non-embedded characteristics  Project staff  Reengineering factors ++

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 Degree of rigor (2)  Task Set Selector Adaptation criteria Grade (1 to 5) Weight Entry point multiplier Product ConceptNDev.Enhan.Maint.Reeng. Size of project Number of users Business criticality Longevity Stability of requirements Ease of communication Maturity of technology Performance constraints Embedded/non-embedded Project staffing interoperability Reengineering facators

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 Degree of rigor (3)  Task Set Selector – example of New Application Development Project Adaptation criteria Grade (1 to 5) Weight Entry point multiplier Product ConceptNDev.Enhan.Maint.Reeng. Size of project Number of users Business criticality Longevity Stability of requirements Ease of communication Maturity of technology Performance constraints Embedded/non-embedded Project staffing interoperability Reengineering facators

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  Interpreting the TSS value Degree of rigor (4) Task Set Selector Value Degree of Rigor TSS < 1.2 Casual 1.0 < TSS < 3.0 Structured TSS > 2.4 Strict  Degree of Rigor  Casual  All process frameworks are applied, only a minimum task set is required  Umbrella task is minimized & documentation is reduced  Structured  All process frameworks are applied; framework activities & related tasks are applied  Umbrella activities, SQA, SCM, documentation, measurement task  Strict  Full process, umbrella activities  Quick Reaction  Process framework is applied, only essential tasks applied  Documentation, reviews conducted after delivery The overlap in TSS value is to illustrate that sharp boundaries are impossible to define ++

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 Selecting Software Engineering Tasks -- Example

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 TASK NETWORK  A graphic representation of the task flow for the project  Sometimes used as a mechanism for inputting task sequence and dependencies to an automated tools  The concurrent nature of the tasks may lead to critical path, that is, tasks that must be completed on schedule ++

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

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 SCHEDULING  Method: PERT (Program Evaluation and Review Technique) & CPM (Critical Path Method)  PERT & CPM used to: 1.Determine critical path 2.Establish most likely time estimates for individual task 3.Calculate “boundary times” that define a time “window” for particular task  Task, sometimes called Work Breakdown Structure (WBS) ++

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 SCHEDULING (2) Important boundary times: 1.The earliest time to start, to finish 2.The latest time to start, to finish 3.The earliest time to finish 4.The latest time to finish 5.Total float – amount of surplus time allowed so that the critical path is maintained ++ Go To Network Diagram

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

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 Use Automated Tools to Derive a Timeline Chart

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 ________ stoppage

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 Project tables Work Tasks Planned Start Actual Start Planned Complete Actual Complete Assigned person Effort Allocated Notes 1.1 Identify needs Wk1, d1 Wk1, d2 BLS 2 p-d ++

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 Tracking the schedule  Conducting periodic project status meeting  Evaluating the results of all reviews  Determining whether milestones have been accomplished by scheduled date  Comparing actual start-date to planned start date  Meeting informally with practitioners  Use earned value analysis to assess progress quantitatively ++

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 Tracking the schedule (2) Time Boxing:  Project scheduling and control technique used when faced with severe deadline pressure  Complete product may not be deliverable by the predefined deadline  Incremental paradigm is chosen  Task with each increment are time boxed, ie, the schedule for each task is adjusted by moving backward from the delivery date.  When a task hits the boundary of time box (  10%), works stop & the next task begins ++

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 EARNED VALUE ANALYSIS (EVA) Using only actual and planned costs can mislead management and customers  Eg. A project has duration of 10 month & a cost of $200,000/month (total cost = $2 million)  For the first 5 months, actual cost is $1,3 million  Is there a cost overrun of $300,000?  Or, is it ahead of schedule?  For the first 5 months, actual cost is $0.8 million  Is the cost less than expected by $200,000?  Or, is it behind schedule? Need to keep track schedules and budgets against time ++

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 EARNED VALUE ANALYSIS (EVA) Steps: 1.Determine BCWS (Budgeted Cost of Work Scheduled) for each task  Baseline 2.BAC (Budget at Completion) = sum of all BCWS 3.Compute BCWP (Budgeted Cost of Work Performed)  Earned Value 4.Compute ACWP (Actual Cost of Work Performed)  Actual Cost ++

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 Example % 100% 50% 75% 85% $400 $340 $300 $200 $100 BCWP Earned Value BCWS Baseline ACWP Actual Cost SVCV duration ++

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 Interpretation of Graph  At the end of period 25, 75% of work was scheduled to be accomplished (BSWS)  At the end of period 25, the value of the work accomplished is 50% (BCWP)  At the end of period 25, the actual cost is $340 or 85%(ACWP)  Cost Variance shows that the project is over budget by $140 ($200 - $340)  Schedule Variance suggests that the project is behind schedule ($200 - $300 = -$100) ++

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 EVA (2)  Schedule performance index, SPI = BCWP/BCWS  Schedule variance, SV = BCWP – BCWS  % schedule for completion = BCWS/BAC  % complete = BCWP/BAC  Cost performance index, CPI = BCWP/ACWP  Cost variance, CV = BCWP - ACWP ++

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 ERROR TRACKING  Defect Removal Efficiency (DRE) = E/(E+D), where E is error before delivery & D is defect found after delivery  Metrics:  Errors per requirements specification page, E reg  Errors per component – design level, E design  Errors per component – code level, E code  DRE – requirement analysis  DRE – architectural design  DRE – component level design  DRE – coding ++