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

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

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

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

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

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

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

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

Effort Allocation “front end” activities 40-50% 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

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

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

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

Defining Task Sets Activity Major work unit Start date End date Consumes resources Results in work products (and milestones) 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

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

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

Activity network SWE311_Ch24 (071) Software & Software Engineering

Activity timeline SWE311_Ch24 (071) Software & Software Engineering

Staff allocation SWE311_Ch24 (071) Software & Software Engineering

Use Automated Tools to Derive a Timeline Chart SWE311_Ch24 (071) Software & Software Engineering

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

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

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

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

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

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

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

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

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

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

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