Chapter 24 Project Scheduling and Tracking

1. Chapter 24Project Scheduling and Tracking SWE311_Ch24 (071) Software & Software Engineering

2. 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 SWE311_Ch24 (071) Software & Software Engineering

3. How to Deal With Unrealistic Schedule Demands • Perform a detailed project estimate for project effort and duration using historical data. • Use an incremental process model that will deliver critical functionality imposed by deadline, but delay other requested functionality. • Meet with the customer and explain why the deadline is unrealistic using your estimates based on prior team performance. • Offer an incremental development and delivery strategy as an alternative to increasing resources or allowing the schedule to slip beyond the deadline. SWE311_Ch24 (071) Software & Software Engineering

4. Project Scheduling Perspectives • One view is that the end-date for the software release is set externally and that the software organization is constrained to distribute effort in the prescribed time frame. • Another view is that the rough chronological bounds have been discussed by the developers and customers, but the end-date is best set by the developer after carefully considering how to best use the resources needed to meet the customer's needs. SWE311_Ch24 (071) Software & Software Engineering

5. Scheduling Principles • compartmentalization— the product and process must be decomposed into a manageable number of activities and tasks • interdependency—indicate task interrelationship • Time allocation - every task has start and completion dates that take the task interdependencies into account • effort validation—be sure resources are available • defined responsibilities— every scheduled task needs to be assigned to a specific team member • defined outcomes—each task must have an output • defined milestones— a milestone is accomplished when one or more work products from an engineering task have passed quality review SWE311_Ch24 (071) Software & Software Engineering

6. Relationship Between People and Effort • Common myth: • Adding people to a project after it is behind schedule often causes the schedule to slip further • The relationship between the number of people on a project and overall productivity is not linear (e.g., 3 people do not produce 3 times the work of 1 person, if the people have to work in cooperation with one another) • The main reasons for using more than 1 person on a project are to get the job done more rapidly and to improve software quality. SWE311_Ch24 (071) Software & Software Engineering

7. Effort and Delivery Time SWE311_Ch24 (071) Software & Software Engineering

8. Identify Identify activity Estimate resources Allocate people Create project activities dependencies for activities to activities char ts Activity, bar, Gantt Charts Software requirements The project scheduling process SWE311_Ch24 (071) Software & Software Engineering

9. Effort Allocation • “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 40-50% 15-20% 30-40% SWE311_Ch24 (071) Software & Software Engineering

10. Project Effort Distribution • The 40-20-40 rule (a rule of thumb): • 40% front-end analysis and design • 20% coding • 40% back-end testing • Generally accepted guidelines are: • 02-03 % planning • 10-25 % requirements analysis • 20-25 % design • 15-20 % coding SWE311_Ch24 (071) Software & Software Engineering

11. Software Project Types • Concept development - initiated to explore new business concept or new application of technology • New application development - new product requested by customer • Application enhancement - major modifications to function, performance, or interfaces (observable to user) • Application maintenance - correcting, adapting, or extending existing software (not immediately obvious to user) • Reengineering - rebuilding all (or part) of a legacy system SWE311_Ch24 (071) Software & Software Engineering

12. Factors Affecting Task Set • A task set is a collection of software engineering work tasks, milestones, and work products that must be accomplished to complete a particular project • Size of project • Number of potential users • Mission criticality • Application longevity • Requirement stability • Ease of customer/developer communication • Maturity of applicable technology • Performance constraints • Embedded/non-embedded characteristics • Project staffing • Reengineering factors SWE311_Ch24 (071) Software & Software Engineering

13. Activity Major work unit Start date End date Consumes resources Results in work products (and milestones) Defining Task Sets Step 1 Step 2 Activity 1 Activity 2 Activity 3 Phase 1 Step 1 Step 2 Activity 1 Activity 2 Task 1 Task 2 Task 3 Project Phase 2 Step 1 Step 2 Phase N SWE311_Ch24 (071) Software & Software Engineering

14. Scheduling • Task networks (activity networks) are graphic representations that can be of the task interdependencies and can help define a rough schedule for particular project • Scheduling tools should be used to schedule any non-trivial project. • PERT (program evaluation and review technique) and CPM (critical path method) are quantitative techniques that allow software planners to identify the chain of dependent tasks in the project work breakdown structure that determine the project duration time. • Timeline (Gantt) charts enable software planners to determine what tasks will need to be conducted at a given point in time (based on estimates for effort, start time, and duration for each task). • The best indicator of progress is the completion and successful review of a defined software work product. SWE311_Ch24 (071) Software & Software Engineering

15. Task durations and dependencies SWE311_Ch24 (071) Software & Software Engineering

16. Activity network SWE311_Ch24 (071) Software & Software Engineering

17. Activity timeline SWE311_Ch24 (071) Software & Software Engineering

18. Staff allocation SWE311_Ch24 (071) Software & Software Engineering

19. Use Automated Tools toDerive a Timeline Chart SWE311_Ch24 (071) Software & Software Engineering

20. Schedule Tracking • conduct periodic project status meetings in which each team member reports progress and problems. • evaluate the results of all reviews conducted throughout the software engineering process. • determine whether formal project milestones (the diamonds shown in Figure 24.3) have been accomplished by the scheduled date. • compare actual start-date to planned start-date for each project task listed in the resource table (Figure 24.4). • meet informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon. • use earned value analysis (Section 24.6) to assess progress quantitatively. SWE311_Ch24 (071) Software & Software Engineering

21. Progress on an OO Project-I • Technical milestone: OO analysis completed • All classes and the class hierarchy have been defined and reviewed. • Class attributes and operations associated with a class have been defined and reviewed. • Class relationships (Chapter 8) have been established and reviewed. • A behavioral model (Chapter 8) has been created and reviewed. • Reusable classes have been noted. • Technical milestone: OO design completed • The set of subsystems (Chapter 9) has been defined and reviewed. • Classes are allocated to subsystems and reviewed. • Task allocation has been established and reviewed. • Responsibilities and collaborations (Chapter 9) have been identified. • Attributes and operations have been designed and reviewed. • The communication model has been created and reviewed. SWE311_Ch24 (071) Software & Software Engineering

22. Progress on an OO Project-II • Technical milestone: OO programming completed • Each new class has been implemented in code from the design model. • Extracted classes (from a reuse library) have been implemented. • Prototype or increment has been built. • Technical milestone: OO testing • The correctness and completeness of OO analysis and design models has been reviewed. • A class-responsibility-collaboration network (Chapter 8) has been developed and reviewed. • Test cases are designed and class-level tests (Chapter 14) have been conducted for each class. • Test cases are designed and cluster testing (Chapter 14) is completed and the classes are integrated. • System level tests have been completed. SWE311_Ch24 (071) Software & Software Engineering

23. Earned Value Analysis • “Earned Value Analysis” is: • a quantitative measure given to each task as a percent of project completed so far • an industry standard way to: • measure a project’s progress • forecast its completion date and final cost, and • provide schedule and budget variances along the way • rather than rely on a gut feeling • By integrating three measurements, it provides consistent, numerical indicators with which you can evaluate and compare projects. SWE311_Ch24 (071) Software & Software Engineering

24. What’s more Important? • Knowing where you are on schedule? • Knowing where you are on budget? • Knowing where you are on work accomplished? SWE311_Ch24 (071) Software & Software Engineering

25. EVA Integrates All Three • It compares the PLANNED amount of work with what has actually been COMPLETED, to determine if COST, SCHEDULE, andWORKACCOMPLISHED are progressing as planned. • Work is “Earned” or credited as it is completed. SWE311_Ch24 (071) Software & Software Engineering

26. Earned Value needed because... • Have an accurate estimate of project status • Provides an “Early Warning” signal for prompt corrective action. • Bad news does not age well. • Still time to recover • Timely request for additional funds SWE311_Ch24 (071) Software & Software Engineering

27. Basic Earned Value Measures • BCWS - Budgeted Cost of Work Scheduled • Planned cost of the total amount of work scheduled to be performed by the milestone date • ACWP - Actual Cost of Work Performed • Cost incurred to accomplish the work that has been done to date • BCWP - Budgeted Cost of Work Performed • The planned (not actual) cost to complete the work that has been done • BAC -Budget At Completion SWE311_Ch24 (071) Software & Software Engineering

28. Derived Earned Value Measures continued • SPI: Schedule Performance Index • SPI = BCWP/BCWS • SPI < 1  project is behind schedule • The closer SPI to 1 indicates more efficient execution of project • CPI: Cost Performance Index • CPI = BCWP/ACWP • CPI < 1  project is over budget • CSI: Cost Schedule Index • CSI = CPI x SPI • The further CSI is from 1.0, the less likely project recovery becomes. SWE311_Ch24 (071) Software & Software Engineering

29. Derived Earned Value Measures • SV: Schedule Variance (BCWP-BCWS) • A comparison of amount of work performed during a given period of time to what was scheduled to be performed. • A negative variance means the project is behind schedule • CV: Cost Variance (BCWP-ACWP) • A comparison of the budgeted cost of work performed with actual cost. • A negative variance means the project is over budget. SWE311_Ch24 (071) Software & Software Engineering

30. Derived Earned Value Measures continued • Percent scheduled for completion = BCWS/BAC • provides an indication of the percentage of work that should have been completed by time t. • Percent complete = BCWP/BAC • provides a quantitative indication of the percent of completeness of the project at a given point in time, t. SWE311_Ch24 (071) Software & Software Engineering