Project Scheduling and Tracking Developed by Reneta Barneva, SUNY Fredonia

Developed by Reneta Barneva, SUNY Fredonia Why a project is late? An unrealistic deadline established by someone outside the software development group and forced on managers and practitioner's within the 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. Developed by Reneta Barneva, SUNY Fredonia

Developed by Reneta Barneva, SUNY Fredonia Why a project is late? 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. Developed by Reneta Barneva, SUNY Fredonia

Software Project Scheduling Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks. The schedule evolves over time. First a macroscopic schedule is developed. It includes all major software engineering activities. Later it is refined to a detailed schedule. Here, specific software tasks are identified and scheduled. Developed by Reneta Barneva, SUNY Fredonia

Principles of Software Project Scheduling Compartmentalization. The project must be split into a number of manageable activities and tasks. To accomplish compartmentalization, both the product and the process are decomposed (Chapter 3). Interdependency. The interdependency of each single activity or task must be determined. Some tasks must occur in sequence while others can occur in parallel. Some activities cannot commence until the work product produced by another is available. Other activities can occur independently. Developed by Reneta Barneva, SUNY Fredonia

Software Project Scheduling Time allocation. Each task to be scheduled must be allocated some number of work units (e.g., person- days of effort). In addition, each task must be assigned a start date and a completion date that are a function of the interdependencies and whether work will be conducted on a full-time or part-time basis. Effort validation. Every project has a defined number of staff members. As time allocation occurs, the project manager must ensure that no more than the allocated number of people have been scheduled at any given time. Developed by Reneta Barneva, SUNY Fredonia

Software Project Scheduling Defined responsibilities. Every task that is scheduled should be assigned to a specific team member. Defined outcomes. Every task that is scheduled should have a defined outcome. For software projects, the outcome is normally a work product (e.g., the design of a module) or a part of a work product. Defined milestones. Every task or group of tasks should be associated with a project milestone. A milestone is accomplished when one or more work products has been reviewed for quality and has been approved. Developed by Reneta Barneva, SUNY Fredonia

The Relation Between People and Effort Example: 4 software engineers, each capable of producing 5000 LOC/year working on an individual project. In a team: six potential communication paths are possible. Assume we have to subtract 250 LOC/year for each communication path Team productivity is 20,000 - (250 x 6) = 18,500 LOC/year—7.5 percent less If two additional people are added to the team two months before the deadline. The number of communication paths becomes 14. The productivity input of the new staff is the equivalent of 840 x 2 = 1680 LOC for the two months. Team productivity now is 20,000 + 1680 - (250 x 14) = 18,180 LOC/year. Developed by Reneta Barneva, SUNY Fredonia

The Relation Between People and Effort There is a nonlinear relationship between chronological time to complete a project and human effort applied to the project. Recalling the software equation introduced in Chapter 5. The number of delivered lines of code L is related to effort and development time by the equation: L = P x E 1/3 t 4/3 E is development effort in person-months, P is a productivity parameter that reflects a variety of factors that lead to high-quality software engineering work (typical values for P range between 2,000 and 12,000), t is the project duration in calendar months. Developed by Reneta Barneva, SUNY Fredonia

The Relation Between People and Effort Rearranging this software equation, we can arrive at an expression for development effort E: E = L 3 / (P 3 t 4) E is the effort (in person-years) for the entire life cycle of software development and maintenance t is the development time in years. Developed by Reneta Barneva, SUNY Fredonia

The Relation Between People and Effort Example: Consider a complex, real-time software project estimated at 33,000 LOC, 12 person-years of effort. If 8 people are assigned to the project team, the project can be completed in approximately 1.3 years. If, however, we extend the end-date to 1.75 years, according to the equation on the previous slide: E = L3/( P3t4) ~ 3.8 person-years. This implies that, by extending the end-date six months, we can reduce the number of people from eight to four! We may use less people over a longer time span to accomplish the same objective. Developed by Reneta Barneva, SUNY Fredonia

Distribution of Efforts Software project estimation techniques lead to estimates of work units (e.g., person-months) required to complete software development. A recommended distribution of effort across the definition and development phases is often referred to as the 40–20–40 rule front-end analysis and design - coding - back-end testing Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Set for the Software Project A task set is a collection of software engineering work tasks, milestones, and deliverables that must be accomplished to complete a particular project. The task set to be chosen must provide enough discipline to achieve high software quality. But, at the same time, it must not burden the project team with unnecessary work. Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Set for the Software Project Task sets are designed to accommodate different types of projects and different degrees of rigor. Most software organizations encounter the following projects: Concept development projects that are initiated to explore some new business concept or application of some new technology. New application development projects that are undertaken as a consequence of a specific customer request. Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Set for the Software Project Application enhancement projects that occur when existing software undergoes major modifications to function, performance, or interfaces that are observable by the end-user. Application maintenance projects that correct, adapt, or extend existing software in ways that may not be immediately obvious to the end-user. Reengineering projects that are undertaken with the intent of rebuilding an existing system in whole or in part. Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Set for the Software Project Four different degrees of rigor can be defined: Casual. All process framework activities are applied, but only a minimum task set is required. Umbrella tasks will be minimized and documentation requirements will be reduced. Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Set for the Software Project Structured. The process framework will be applied for this project. - Framework activities and related tasks appropriate to the project type will be applied - Umbrella activities necessary to ensure high quality will be applied. - Documentation will be provided, and - Measurement tasks will be conducted. Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Set for the Software Project Strict. The full process will be applied for this project with a degree of discipline that will ensure high quality. All umbrella activities will be applied and robust work products will be produced. Quick reaction. The process framework will be applied for this project, but because of an emergency situation only those tasks essential to maintaining good quality will be applied. "Back- filling" (i.e., developing a complete set of documentation) will be accomplished after the application/product is delivered to the customer. Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Set for the Software Project Adaptation criteria: used to determine the recommended degree of rigor. The following adaptation criteria are defined for software projects: Maturity of applicable technology Performance constraints Embedded and non- embedded characteristics Project staff Reengineering factors Size of the project Number of potential users Mission criticality Application longevity Stability of requirements Ease of customer/developer communication Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Set for the Software Project Computing a Task Set Selector Value: 1. Assign appropriate grades (1 to 5) of each of the adaptation criteria based on the characteristics of the project. 2. Review the weighting factors assigned to each of the criteria. The value of a weighting factor ranges from 0.8 to 1.2 and provides an indication of the relative importance of a particular adaptation criterion to the types of software developed within the local environment. 3. Multiply the grades by the weighting factors and by the entry point multiplier. The entry point multiplier takes on a value of 0 or 1 and indicates the relevance of the adaptation criterion to the project type. Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Set for the Software Project Computing a Task Set Selector Value: Compute the average of grade x weighting factor x entry point multiplier for all criteria This value is called task set selector (TSS) and it is used to help select the task set that is most appropriate for the project. Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Set for the Software Project Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Set for the Software Project How to use task set selector value? Degree of rigor TSS < 1.2 casual 1.0 < TSS < 3.0 structured TSS > 2.4 strict Developed by Reneta Barneva, SUNY Fredonia

Selecting Software Engineering Tasks In order to develop a project schedule, a task set must be distributed on the project time line. Depends on the model. Developed by Reneta Barneva, SUNY Fredonia

Selecting Software Engineering Tasks In order to develop a project schedule, a task set must be distributed on the project time line. Depends on the model. Developed by Reneta Barneva, SUNY Fredonia

Refinement of Major Tasks After defining the major tasks, a detailed schedule of the project is created. Refinement begins by taking each major task and decomposing it into a set of subtasks (with related work products and milestones). Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Network Individual tasks and subtasks have interdependencies based on their sequence. In addition, when more than one person is involved in a software engineering project, some tasks may be performed in parallel. A task network (activity network) is a graphic representation of the task flow for a project. Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Network Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Network Project scheduling methods: Program evaluation and review technique (PERT) and Critical path method (CPM). Both of them use information from earlier project planning activities: Estimates of effort A decomposition of the product function The selection of the appropriate process model and task set Decomposition of tasks Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Network Both PERT and CPM provide quantitative tools that allow the software planner to (1) determine the critical path—the chain of tasks that determines the duration of the project; (2) establish "most likely" time estimates for individual tasks by applying statistical models; (3) calculate "boundary times" that define a time "window" for a particular task. Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Network Examples of timeline chart and project table follow Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Network Both PERT and CPM provide quantitative tools that allow the software planner to (1) determine the critical path—the chain of tasks that determines the duration of the project; (2) establish "most likely" time estimates for individual tasks by applying statistical models; (3) calculate "boundary times" that define a time "window" for a particular task. Developed by Reneta Barneva, SUNY Fredonia

Defining a Task Network Developed by Reneta Barneva, SUNY Fredonia

Developed by Reneta Barneva, SUNY Fredonia Tracking the Schedule Tracking can be accomplished in a number of different ways: Conducting periodic project status meetings in which each team member reports progress and problems. Evaluating the results of all reviews conducted throughout the software engineering process. Determining whether formal project milestones have been accomplished by the scheduled date. Comparing actual start-date to planned start-date for each project task listed in the resource table. Meeting informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon. Developed by Reneta Barneva, SUNY Fredonia

Earned Value Analysis - a Method for Tracking the Schedule To determine the earned value, the following steps are performed: 1. The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule. During the estimation activity, the work (in person-hours or person-days) of each software engineering task is planned. BCWSi is the effort planned for work task i. The value of BCWS is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule. Developed by Reneta Barneva, SUNY Fredonia

Earned Value Analysis - a Method for Tracking the Schedule 2. The BCWS values for all work tasks are summed to derive the budget at completion, BAC. BAC =  (BCWSi) for all tasks i 3. Next, the value for budgeted cost of work performed (BCWP) is computed. The value for BCWP is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule. Developed by Reneta Barneva, SUNY Fredonia

Earned Value Analysis - a Method for Tracking the Schedule Schedule performance index: SPI is an indication of the efficiency with which the project is utilizing scheduled resources. An SPI value close to 1.0 indicates efficient execution of the project schedule. SPI = BCWP/BCWS Developed by Reneta Barneva, SUNY Fredonia

Earned Value Analysis - a Method for Tracking the Schedule Schedule variance: SV is an absolute indication of variance from the planned schedule. SV = BCWP - BCWS Developed by Reneta Barneva, SUNY Fredonia

Earned Value Analysis - a Method for Tracking the Schedule 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. Developed by Reneta Barneva, SUNY Fredonia

Developed by Reneta Barneva, SUNY Fredonia The Project Plan Each step in the software engineering process should produce a deliverable that can be reviewed and that can act as a foundation for the steps that follow. The Software Project Plan provides baseline cost and scheduling information that will be used throughout the software process. Developed by Reneta Barneva, SUNY Fredonia

Developed by Reneta Barneva, SUNY Fredonia The Project Plan The Software Project Plan is a relatively brief document that is addressed to a diverse audience. It must (1) communicate scope and resources to software management, technical staff, and the customer; (2) define risks and suggest risk aversion techniques; (3) define cost and schedule for management review; (4) provide an overall approach to software development for all people associated with the project; and (5) outline how quality will be ensured and change will be managed. Developed by Reneta Barneva, SUNY Fredonia