Project Scheduling
- 1. B Y , M . S HA RMI L A D E V I M . S C (I T ) SOFTWARE ENGINEERING PROJECT SCHEDULING
- 2. BASIC CONCEPTS Although there are many reasons why software is delivered late, most can be traced to one or more of the following root causes: An unrealistic deadline established by someone outside the software team and forced on managers and practitioners. 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.
- 3. Project Scheduling Software project scheduling is an action that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks. Scheduling for software engineering projects can be viewed from two rather different perspectives. In the first, an end date for release of a computer-based system has already been established. The software organization is constrained to distribute effort within the prescribed time frame. The second view of software scheduling assumes that rough chronological bounds have been discussed but that the end date is set by the software engineering organization.
- 4. Basic Principles Compartmentalization. The project must be compartmentalized into a number of manageable activities and tasks. Interdependency. The interdependency of each compartmentalized activity or task must be determined. Time allocation. Each task to be scheduled must be allocated some number of work units (e.g., person-days of effort). Effort validation. Every project has a defined number of people on the software team. As time allocation occurs, you must ensure that no more than the allocated number of people has been scheduled at any given time.
- 5. 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. Defined milestones. Every task or group of tasks should be associated with a project milestone. Each of these principles is applied as the project schedule evolves.
- 6. The Relationship Between People and Effort In a small software development project a single person can analyze requirements, perform design, generate code, and conduct tests. As the size of a project increases, more people must become involved. There is a common myth that is still believed by many managers who are responsible for software development projects: “If we fall behind schedule, we can always add more programmers and catch up later in the project.” Unfortunately, adding people late in a project often has a disruptive effect on the project, causing schedules to slip even further.
- 7. The people who are added must learn the system, and the people who teach them are the same people who were doing the work. While teaching, no work is done, and the project falls further behind. In addition to the time it takes to learn the system, more people increase the number of communication paths and the complexity of communication throughout a project. Although communication is absolutely essential to successful software development, every new communication path requires additional effort and therefore additional time.
- 8. The relationship between effort and delivery time
- 9. Over the years, empirical data and theoretical analysis have demonstrated that project schedules are elastic. That is, it is possible to compress a desired project completion date (by adding additional resources) to some extent. It is also possible to extend a completion date (by reducing the number of resources).
- 10. Effort Distribution Each of the software project estimation techniques leads to estimates of work units (e.g., person-months) required to complete software development. A recommended distribution of effort across the software process is often referred to as the 40–20–40 rule. Forty percent of all effort is allocated to frontend analysis and design. A similar percentage is applied to back-end testing. You can correctly infer that coding (20 percent of effort) is deemphasized.
- 11. DEFINING A TASK SET FOR THE SOFTWARE PROJECT 1. Concept development projects that are initiated to explore some new business concept or application of some new technology. 2. New application development projects that are undertaken as a consequence of a specific customer request. 3. Application enhancement projects that occur when existing software undergoes major modifications to function, performance, or interfaces that are observable by the end user. 4. Application maintenance projects that correct, adapt, or extend existing software in ways that may not be immediately obvious to the end user. 5. Reengineering projects that are undertaken with the intent of rebuilding an existing (legacy) system in whole or in part.
- 12. A Task Set Example Concept scoping determines the overall scope of the project. Preliminary concept planning establishes the organization’s ability to undertake the work implied by the project scope. Technology risk assessment evaluates the risk associated with the technology to be implemented as part of the project scope. Proof of concept demonstrates the viability of a new technology in the software context. Concept implementation implements the concept representation in a manner that can be reviewed by a customer and is used for “marketing” purposes when a concept must be sold to other customers or management. Customer reaction to the concept solicits feedback on a new technology concept and targets specific customer applications.
- 13. DEFINING A TASK NETWORK A task network, also called an activity network, is a graphic representation of the task flow for a project. It is sometimes used as the mechanism through which task sequence and dependencies are input to an automated project scheduling tool.
- 14. A task network for concept development
- 15. SCHEDULING Scheduling of a software project does not differ greatly from scheduling of any multitask engineering effort. Program evaluation and review technique (PERT) and the critical path method (CPM) are two project scheduling methods that can be applied to software development. Interdependencies among tasks may be defined using a task network. Tasks, sometimes called the project work breakdown structure (WBS), are defined for the product as a whole or for individual functions
- 16. Both PERT and CPM provide quantitative tools that allow you 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, and (3) calculate “boundary times” that define a time “window” for a particular task.
- 17. Time-Line Charts When creating a software project schedule, you begin with a set of tasks (the work breakdown structure). If automated tools are used, the work breakdown is input as a task network or task outline. Effort, duration, and start date are then input for each task. In addition, tasks may be assigned to specific individuals. As a consequence of this input, a time-line chart, also called a Gantt chart, is generated. A time-line chart can be developed for the entire project. Alternatively, separate charts can be developed for each project function or for each individual working on the project.
- 18. An example time-line chart
- 19. 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 the actual start date to the 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 Using earned value analysis to assess progress quantitatively
- 20. An example project table
- 21. Tracking Progress for an OO Project 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 have been established and reviewed. A behavioral model has been created and reviewed. Reusable classes have been noted.
- 22. Technical milestone: OO design completed The set of subsystems has been defined and reviewed. Classes are allocated to subsystems and reviewed. Task allocation has been established and reviewed Responsibilities and collaborations have been identified. Attributes and operations have been designed and reviewed. The communication model has been created and reviewed.
- 23. 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.
- 24. Technical milestone: OO testing The correctness and completeness of OO analysis and design models has been reviewed. A class-responsibility-collaboration network has been developed and reviewed. Test cases are designed, and class-level tests have been conducted for each class. Test cases are designed, and cluster testing is completed and the classes are integrated. System-level tests have been completed.
- 25. Scheduling for WebApp Projects WebApp project scheduling distributes estimated effort across the planned time line (duration) for building each WebApp increment. This is accomplished by allocating the effort to specific tasks. seven increments can be identified for the Web-based component of the project: Increment 1: Basic company and product information Increment 2: Detailed product information and downloads
- 26. Increment 3: Product quotes and processing product orders Increment 4: Space layout and security system design Increment 5: Information and ordering of monitoring services Increment 6: Online control of monitoring equipment Increment 7: Accessing account information
- 27. The team consults and negotiates with stakeholders and develops a preliminary deployment schedule for all seven increments. A time-line chart for this schedule
- 28. To illustrate, consider a generic design modeling action for WebApps that can be accomplished by applying some or all of the following tasks: Design the aesthetic for the WebApp. Design the interface. Design the navigation scheme. Design the WebApp architecture. Design the content and the structure that supports it. Design functional components. Design appropriate security and privacy mechanisms. Review the design.
- 29. The following subtasks are derived for the Design the Interface task for the fourth increment: Develop a sketch of the page layout for the space design page. Review layout with stakeholders. Design space layout navigation mechanisms. Design “drawing board” Develop procedural details for the graphical wall layout function. Develop procedural details for the wall length computation and display function. Develop procedural details for the graphical window layout function. Develop procedural details for the graphical door layout function. Design mechanisms for selecting security system components (sensors, cameras, microphones, etc.). Develop procedural details for the graphical layout of security system components. Conduct pair walkthroughs as required.
- 30. EARNED VALUE ANALYSIS 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 estimation, the work (in person-hours or person-days) of each software engineering task is planned. Hence, BCWSi is the effort planned for work task i. To determine progress at a given point along the project schedule, 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. 2. The BCWS values for all work tasks are summed to derive the budget at completion (BAC). 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.
- 31. Given values for BCWS, BAC, and BCWP, important progress indicators can be computed: Schedule performance index, SPI = BCWP/BCWS Schedule variance, SV = BCWP – BCWS 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
- 32. It is also possible to compute the actual cost of work performed (ACWP). The value for ACWP is the sum of the effort actually expended on work tasks that have been completed by a point in time on the project schedule. It is then possible to compute Cost performance index, CPI = BCWP/ACWP Cost variance, CV = BCWP - ACWP
- 33. CONCLUSION Scheduling is the culmination of a planning activity that is a primary component of software project management. Scheduling begins with process decomposition. The characteristics of the project are used to adapt an appropriate task set for the work to be done. A task network depicts each engineering task, its dependency on other tasks, and its projected duration. The task network is used to compute the critical path, a time- line chart, and a variety of project information. Using the schedule as a guide, you can track and control each step in the software process.