| HOME | Project Management Data Warehousing / Mining Software Testing | Technical Writing |
|
In this section, we look at:
As we saw in the previous sections, the software development cycle includes many steps, some of which are repeated until the system is complete and the customers and users are satisfied. However, before committing funds for a software development or maintenance project, a customer usually wants an estimate of how much the project will cost and how long the project will take. This section examines the activities necessary to plan and manage a software development project. 1. TRACKING PROGRESS Software is useful only if it performs a desired function or provides a needed service. Thus, a typical project begins when a customer approaches you to discuss a perceived need. For example, a large national bank may ask you for help in building an information system that allows the bank's clients to access their account information, no matter where in the world the clients are. Or you may be contacted by marine biologists who ., would like a system to connect with their water-monitoring equipment and perform statistical analyses of the data gathered. Usually, customers have several questions to be answered:
How much will it cost to have you develop such a system? an activity has a beginning and an end, whereas a milestone is the end of a specially designated activity. For example, the customer may want the system to be accompanied by an online operator tutorial. The development of the tutorial and its associated pro grams is an activity; it culminates in the demonstration of those functions to the customer: the milestone. By examining the project carefully in this way, we can separate development into a succession of phases. Each phase is composed of steps, and each step can be subdivided further if necessary, as shown in FIG. 1. To see how this analysis works, consider the phases, steps, and activities of TABLE 1, which describes the building of a house. First, we consider two phases: landscaping the lot and building the house itself. Then, we break each phase into smaller steps, such as Answering the last two questions requires a well -thought-out project schedule. A project schedule describes the software development cycle for a particular project by enumerating the phases or stages of the project and breaking each into discrete tasks or activities to be done. The schedule also portrays the interactions among these activities and estimates the time that each task or activity will take. Thus, the schedule is a time line that shows when activities will begin and end, and when the related development products will be ready. In Section 1, we learned that a systems approach involves both analysis and synthesis: breaking the problem into its component parts, devising a solution for each part, and then putting the nieces together to form a coherent whole. We can use this approach to determine the project schedule. We begin by working with customers and potential users to understand what they want and need. At the same time, we make sure that they are comfortable with our knowledge of their needs. We list all project deliverables, that is, the items that the customer expects to see during project development. Among the deliverables may be:
Next, we determine what activities must take place in order to produce these deliverables. We may use some of the process modeling techniques we learned in Section 2, laying out exactly what must happen and which activities depend on other activities, products, or resources. Certain events are designated to be milestones, indicating to us and our customers that a measurable level of progress has been made. For example, when the requirements are documented, inspected for consistency and completeness, and turned over to the design team, the requirements specification may be a project milestone. Similarly, milestones may include the completion of the user's manual, the performance of a given set of calculations, or a demonstration of the system's ability to communicate with another system. In our analysis of the project, we must distinguish clearly between milestones and activities. An activity is a part of the project that takes place over a period of time, whereas a milestone is the completion of an activity-a particular point in time. Thus, clearing and grubbing, seeding the turf, and planting trees and shrubs. Where necessary, we can divide the steps into activities; for example, finishing the interior involves completing the interior plumbing, interior electrical work, wallboard, interior painting, floor covering, doors, and fixtures. Each activity is a measurable event and we have objective criteria to determine when the activity is complete. Thus, any activity's end can be a mile stone, and TABLE 2 lists the milestones for phase 2. This analytical breakdown gives us and our customers an idea of what is involved in constructing a house. Similarly, analyzing a software development or maintenance project and identifying the phases, steps, and activities, both we and our customers have a better grasp of what is involved in building and maintaining a system. We saw in Section 2 that a process model provides a high-level view of the phases and steps, so process modeling is a useful way to begin analyzing the project. In later sections, we will see that the major phases, such as requirements engineering, implementation, or testing, involve many activities, each of which contributes to product or process quality. TABLE 1 Phases, Steps, and Activities of Building a House Work Breakdown and Activity Graphs Analysis of this kind is sometimes described as generating a work breakdown structure for a given project, because it depicts the project as a set of discrete pieces of work. Notice that the activities and milestones are items that both customer and developer can use to track development or maintenance. At any point in the process, the customer may want to follow our progress. We developers can point to activities, indicating what work is under way, and to milestones, indicating what work has been completed. How ever, a project's work breakdown structure gives no indication of the interdependence of the work units or of the parts of the project that can be developed concurrently. We can describe each activity with four parameters: the precursor, duration, due date, and endpoint. A precursor is an event or set of events that must occur before the activity can begin; it describes the set of conditions that allows the activity to begin. The duration is the length of time needed to complete the activity. The due date is the date by which the activity must be completed, frequently determined by contractual deadline. Signifying that the activity has ended, the endpoint is usually a milestone or deliverable. We can illustrate the relationships among activities by using these parameters. In particular, we can draw an activity graph to depict the dependencies; the nodes of the graph are the project milestones, and the lines linking the nodes represent the activities involved. FIG. 2 is an activity graph for the work described in phase 2 of TABLE 1. TABLE 2 Milestones in Building a House 1.1. Survey complete 1.2. Permits issued 1.3. Excavation complete 1.4. Materials on hand 2.1. Foundation laid 2.2. Outside walls complete 2.3. Exterior plumbing complete 2.4. Exterior electrical work complete 2.5. Exterior siding complete 2.6. Exterior painting complete 2.7. Doors and futures mounted 2.8. Roof complete 3.1. Interior plumbing complete 3.2. Interior electrical work complete 3.3. Wallboard in place 3.4. Interior painting complete 3.5. Floor covering laid 3.6. Doors and fixtures mounted
Many important characteristics of the project are made visible by the activity graph. For example, it is clear from FIG. 2 that neither of the two plumbing activities can start before milestone 2.2 is reached; that is, 2.2 is a precursor to both interior and exterior plumbing. Furthermore, the figure shows us that several things can be done simultaneously. For instance, some of the interior and exterior activities are independent (such as installing wallboard, connecting exterior electrical plumbing, and others leading to milestones 2.6 and 3.3, respectively). The activities on the left-hand path do not depend on those on the right for their initiation, so they can be worked on concurrently. Notice that there is a dashed line from requesting permits (node 1.2) to surveying (node 1S1. This line indicates that these activities must he completed before excavation (the activity leading to milestone L3) can begin. However, since there is no real activity that occurs after reaching milestone 1.2 in order to get to milestone 1.1, the dashed line indicates a relationship without an accompanying activity. It is important to realize that activity graphs depend on an understanding of the parallel nature of tasks. If work cannot be done in parallel, then the (mostly straight) graph is not useful in depicting how tasks will be coordinated. Moreover, the graphs must reflect a realistic depiction of the parallelism. In our house-building example, it is clear that some of the tasks, like plumbing, will be done by different people from those doing other tasks, like electrical work. But on software development projects, where some people have many skills, the theoretical parallelism may not reflect reality. A restricted number of people assigned to the project may result in the same person doing many things in series, even though they could be done in parallel by a larger development team. Estimating Completion We can make an activity graph more useful by adding to it information about the estimated time it will take to complete each activity. For a given activity, we label the corresponding edge of the graph with the estimate. For example, for the activities in phase 2 of Table 2.1, we can append to the activity graph of FIG. 2 estimates of the number of days it will take to complete each activity. TABLE 3 contains the estimates for each activity. The result is the graph shown in FIG. 3. Notice that milestones 2.7, 2.8, 3.4, and 3.6 are precursors to the finish. That is, these milestones must all be reached in order to consider the project complete. The zeros on the links from those nodes to the finish show that no additional time is needed. There is also an implicit zero on the link from node 1.2 to 1.1, since no additional time is accrued on the dashed link. This graphical depiction of the project tells us a lot about the project's schedule. For example, since we estimated that the first activity would take 3 days to complete, we cannot hope to reach milestone 1.1 before the end of day 3. Similarly, we cannot reach milestone 1.2 before the end of day 15. Because the beginning of excavation (activity 1.3) cannot begin until milestones 1.1 and 1.2 are both reached, excavation cannot begin until the beginning of day 16. TABLE 3 Activities and Time Estimates Analyzing the paths among the milestones of a project in this way is called the Critical Path Method (CPM). The paths can show us the minimum amount of time it will take to complete the project, given our estimates of each activity's duration. Moreover, CPM reveals those activities that are most critical to completing the project on time. To see how CPM works, consider again our house-building example. To see how CPM works, consider again our house-building example. First, we notice that the activities leading to milestones 1.1 (surveying) and 1.2 (requesting permits) can occur concurrently. Since excavation (the activity culminating in milestone 1.3) cannot begin until day 16, surveying has 15 days in which to be completed, even though it is only 3 days in duration. Thus, surveying has 15 days of available time, but requires only 3 days of real time. In the same way, for each activity in our graph, we can compute a pair of times: real time and available time. The real time or actual time for an activity is the estimated amount of time required for the activity to be completed, and the available time is the amount of time available in the schedule for the activity's completion. Slack time or float for an activity is the difference between the available time and the real time for that activity: Slack time = available time - real time
Another way of looking at slack time is to compare the earliest time an activity may begin with the latest time the activity may begin without delaying the project. For example, surveying may begin on day 1, so the earliest start time is day 1. However, because it will take 15 days to request and receive permits, surveying can begin as late as day 13 and still not hold up the project schedule. Therefore, Slack time = latest start time - earliest start time Let us compute the slack for our example's activities to see what it tells us about the project schedule. We compute slack by examining all paths from the start to the finish. As we have seen, it must take 15 days to complete milestones 1.1 and 1.2. An additional 55 days are used in completing milestones 1.3, 1.4, 2.1, and 2.2. At this point, there are four possible paths to be taken: 1. Following milestones 2.3 through 2.7 on the graph requires 39 days. 2. Following milestones 2.3 through 2.8 on the graph requires 42 days. 3. Following milestones 3.1 through 3.4 on the graph requires 54 days. 4. Following milestones 3.1 through 3.6 on the graph requires 54 days. Because milestones 2.7, 2.8, 3.4, and 3.6 must be met before the project is finished, our schedule is constrained by the longest path. As you can see from FIG. 3 and our preceding calculations, the two paths on the right require 124 days to complete, and the two paths on the left require fewer days. To calculate the slack, we can work backward along the path to see how much slack time there is for each activity leading to a node. First, we note that there is zero slack on the longest path. Then, we examine each of the remaining nodes to calculate the slack for the activities leading to them. For example, 54 days are available to complete the activities leading to milestones 2.3, 2.4, 2.5, 2.6, and 2.8, but only 42 days are needed to complete these. Thus, this portion of the graph has 12 days of slack. Similarly, the portion of the graph for activities 2.3 through 2.7 requires only 39 days, so we have 15 days of slack along this route. By working forward through the graph in this way, we can compute the earliest start time and slack for each of the activities. Then, we compute the latest start time for each activity by moving from the finish back through each node to the start. TABLE 4 shows the results: the slack time for each activity in FIG. 3. (At milestone 2.6, the path can branch to 2.7 or 2.8. The latest start times in TABLE 4 are calculated by using the route from 2.6 to 2.8, rather than from 7..6 to 7..71 The longest path has a slack of zero for each of its nodes, because it is the path that determines whether or not the project is on schedule. For this reason, it is called the critical path. Thus, the critical path is the one for which the slack at every node is zero. As you can see from our example, there may be more than one critical path. TABLE 4 Slack time for Project Activities Since the critical path has no slack, there is no margin for error when performing the activities along its route. Notice what happens when an activity on the critical path begins late (i.e., later than its earliest start time). The late start pushes all subsequent critical path activities forward, forcing them to be late, too, if there is no slack. And for activities not on the critical path, the subsequent activities may also lose slack time. Thus, the activity graph helps us to understand the impact of any schedule slippage. Consider what happens if the activity graph has several loops in it. Loops may occur when an activity must be repeated. For instance, in our house -building example, the building inspector may require the plumbing to he redone. In software development, a design inspection may require design or requirements to be re-specified. The appearance of these loops may change the critical path as the loop activities are exercised more than once. In this case, the effects on the schedule are far less easy to evaluate. FIG. 4 is a bar chart that shows some software development project activities, including information about the early and late start dates; this chart is typical of those produced by automated project management tools. The horizontal bars represent the duration of each activity; those bars composed of asterisks indicate the critical path. Activities depicted by dashes and Fs are not on the critical path, and an F represents float or slack time. Critical path analysis of a project schedule tells us who must wait for what as the project is being developed. It also tells us which activities must be completed on schedule to avoid delay. This kind of analysis can be enhanced in many ways. For instance, our house-building example supposes that we know exactly how long each activity will take. Often, this is not the case. Instead, we have only an estimated duration for an activity, based on our knowledge of similar projects and events. Thus, to each activity, we can assign a probable duration according to some probability distribution, so that each activity has associated with it an expected value and a variance. In other words, instead of knowing an exact duration, we estimate a window or interval in which the actual time is likely to fall. The expected value is a point within the interval, and the variance describes the width of the interval. You may be familiar with a standard probability distribution called a normal distribution, whose graph is a bell -shaped curve. The Program Evaluation and Review Technique (PERT) is a popular critical path analysis technique that assumes a normal distribution. (See Hillier and Lieberman [2001] for more information about PERT.) PERT determines the probability that the earliest start time for an activity is close to the scheduled times for that activity T Nino information such as probability distribution latest and earliest start times, and the activity graph, a PERT program can calculate the critical path and identify those activities most likely to be bottlenecks. Many project man agers use the CPM or PERT method to examine their projects. However, these methods are valuable only for stable projects in which several activities take place concurrently. If the project's activities are mostly sequential, then almost all activities are on the critical path and are candidates for bottlenecks Moreover, if the project requires redesign or rework, the activity graph and critical path are likely to change during development.
Tools to Track Progress There are many tools that can be used to keep track of a project's progress. Some are manual, others are simple spreadsheet applications, and still others are sophisticated tools with complex graphics. To see what kinds of tools may be useful on your projects, consider the work breakdown structure depicted in FIG. 5. Here, the overall objective is to build a system involving communications software, and the project manager has described the work in terms of five steps: system planning, system design, coding, testing, and delivery. For simplicity, we concentrate on the first two steps. Step 1 is then partitioned into four activities: reviewing the specifications, reviewing the budget, reviewing the schedule, and developing a project plan. Similarly, the system design is developed by doing a top-level design, prototyping, designing the user interface, and then creating a detailed design. Many project management software systems draw a work breakdown structure and also assist the project manager in tracking progress by step and activity. For example, a project management package may draw a Gantt chart, a depiction of the project where the activities are shown in parallel, with the degree of completion indicated by a color or icon. The chart helps the project manager to understand which activities can be performed concurrently, and also to see which items are on the critical path. FIG. 6 is a Gantt chart for the work breakdown structure of FIG. 5. The project began in January, and the dashed vertical line labeled "today" indicates that the J 0 project team is working during the middle of May. A vertical bar shows progress on each activity, and the color of the bar denotes completion, duration, or criticality. A diamond icon shows us where there has been slippage, and the triangles designate an activity's start and finish. The Gantt chart is similar to the CPM chart of FIG. 4, but it includes more information.
Simple charts and graphs can provide information about resources, too. For example, FIG. 7 graphs the relationship between the people assigned to the project and those needed at each stage of development; it is typical of graphs produced by project management tools. It is easy to see that during January, February, and March, people are needed but no one is assigned. In April and May, some team members are working, but not enough to do the required job. On the other hand, the period during which there are too many team members is clearly shown: from the beginning of June to the end of September. The resource allocation for this project is clearly out of balance. By changing the graph's input data, you can change the resource allocation and try to reduce the overload, finding the best resource load for the schedule you have to meet. Later in this section, we will see how to estimate the costs of development.
Project management tools track actual costs against the estimates, so that budget progress can be assessed, too. FIG. 8 shows an example of how expenditures can be monitored. By combining budget tracking with personnel tracking, you can use project management tools to determine the best resources for your limited budget. NEXT>> |
