CS302: Software Engineering

To plan the project, the project manager works with the SE to determine human, computer, and organizational resources required to develop the application. While a detailed discussion of planning is included in Chapter 6, the aspects of special interest to the project manager are in this section. 

A project plan is a map of tasks, times, and their interrelationships. It can be very general (see Figure 3-1) or very specific (see Figure 3-2). Neither extreme of plan is very useful although some plan is better than none. A rule of thumb for level of detail is to define activities for which a weekly review of progress allows the SE and project manager to know whether the schedule is being met. Figure 3-3 shows an example of a well-defined plan. 

The general methodology of planning is as follows: 

1. List tasks. Include application development tasks, project specific tasks, interface organization tasks, and review and approval tasks. 

2. Identify dependencies between tasks. 

3. Assign personnel either by name or by skill and experience level.

4. Assign completion times to tasks; compute the most likely time for each. 

5. Identify the critical path.

FIGURE 3-2 Example of Too Detailed a Plan

The project manager and SE share responsibility for developing the plan. The SE's responsibility is to know all of the tasks relating to the application being developed; the project manager's responsibility is to ensure that all organizationally related tasks are included in the list. (The application tasks are discussed in Chapter 6.) Organization tasks include the following:

1. Review documents for completeness, content, consistency, and accuracy. Complementary Activities 59 

2. Negotiate, agree, and commit to start and end dates for work.

3. Define necessary application interfaces; plan for detailed interface design work.

FIGURE 3-3 Example of Acceptable Level of Detail

All documentation, plans, and design work of the project team is subject to review by at least the user/sponsor. Many other departments or organizations might also be required to review some or all of the work. These organizations might include managers of IS, users, quality assurance, legal, audit, operations, other application groups, government regulators, industry regulators, or others. Each organization applies its specialized knowledge to the application documents to assess their adequacy. 

The second task is to obtain agreement and commitments from outside agencies or departments. Frequently, resources and work are provided by other departments. Clerical support, for example, might be from an Administrative Services Department. Operations departments supply support in terms of computer time, memory, disk space, terminals, logon IDs, access to software environments, access to data bases, and so on as necessary to develop and test the application. Auditors frequently want to comment on auditing plans and change the design based on their findings. Quality assurance departments might review documents to find inconsistencies and errors that" require correction. Vendors might need to install hardware, software, or related applications that need liaison from the project team and testing once installed. All of these activities need to be scheduled and planned. Since dates for commitments might not be known when the plan IS developed, the plan contains the dates at which contact should be initiated and dates by which the commitment must be made in order not to impact the delivery date.

Third, the project manager obtains requirements for application interfaces from other application areas. An interface is data that is sent or received between applications. The interface application areas might be in the same company, but might also be an industry group or a government organization. The plan reflects dates by which contact should be initiated and by which the information is required. 

If a make-or-buy decision will be made, the project manager and SE work together to develop the subplan for this decision. Sub activities relating to acquisitions include creating and submitting requests for a proposal (RFP), obtaining vendor quotes, evaluating vendor quotes, selecting and obtaining management approval for a vendor, negotiating contract and delivery dates, and planning and testing of the acquired item. 

When all of the items are identified, they are related to each other. Tasks that are related are drawn on a task dependency diagram showing the sequences of dependencies. Sequences may be interdependent (see Figure 3-4). When all sequences of tasks are on the diagram, independent tasks are added. Milestones, such as the completion of a feasibility analysis document, are shown and are visually obvious because the preceding" sets of tasks all feed into that task. Task sequencing can vary depending on the methodology used. (See Chapter 6 for more on this topic.)

Sequencing tasks is the first step to identifying the critical path of tasks for the application's development. The critical path is the sequence of dependent tasks that together take the most development time. If any of the tasks in the critical path are delayed, the project is also delayed. So, the critical path tasks are the greatest source of risk for project completion. 

The next step is to estimate the amount of work. For this discussion, we assume the project manager and SE assign times to tasks based on their experience (i.e., reasoning by analogy). Other methods are discussed in Chapter 6. Times are assigned to each task based on its complexity and amount of work. Three times should be estimated: an optimistic time, a realistic time, and a pessimistic time. The formula used to compute the most likely time is shown in Figure 3-5. The figure weights the most likely, realistic time by a factor of two in relation to the other estimates.

While times ate being assigned, the skill sets and experience levels of a person to do this task should be defined. The list of skill sets and experience levels is used to determine how many people and what type of people are required on the project for each phase. Other assumptions will surface, and a list of them should be kept, as shown in Table 3-1. The assumptions become part of the planning document. 

When resource requirements and timing are complete, several activities take place. The SE develops a schedule; the project manager develops a budget. They both identify the critical path and discuss it in terms of potential problems and how to minimize their likelihood. Task definitions are made more detailed for critical tasks, to allow more control and monitoring.

FIGURE 3-4 Example of Interdependent Sequences of Tasks

FIGURE 3-5 Formula for Determining Schedule Time

When complete, the plan, schedule and budget are submitted to the user and IS managers for comment and approval. Work begins, if it hasn't already, with the plan used to guide project work. The plan is used by the project team to see where their work fits in the whole project, and it is used to monitor progress toward project completion.

TABLE 3-1 Project Assumptions

The plan should never be cast in concrete. Plans should change when the tasks are wrong, times are underestimated, or there are changes in project scope that alter the activities performed in some way.