CHANGES IN SOFTWARE
WBS 2.0 SYSTEM DESIGN
JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC
1.1 Review specification 1.2 Review budget 1.3 Review schedule 1.4 Develop plan
2.1 Top-level design 2.2 Prototyping 2.3 User interface 2.4 Detailed design
Completed Duration Float Critical Slippage Start task Finish task TODAY
Specification approved
Budget approved Schedule approved
Plan approved
Design approved
Design approved
FIGURE 3.6 Gantt chart for example work breakdown structure.
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 indi- cated by a color or icon.The chart helps the project manager to understand which activ- ities can be performed concurrently, and also to see which items are on the critical path.
Figure 3.6 is a Gantt chart for the work breakdown structure of Figure 3.5. The project began in January, and the dashed vertical line labeled “today” indicates that the 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 dia- mond icon shows us where there has been slippage, and the triangles designate an activ- ity’s start and finish. The Gantt chart is similar to the CPM chart of Figure 3.4, but it includes more information.
Simple charts and graphs can provide information about resources, too. For example, Figure 3.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, Section 3.1 Tracking Progress 93
JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC
PROJECTED STAFF-DAYS
Load Overload Underload FIGURE 3.7 Resource
histogram.
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 chapter, 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. Figure 3.8 shows an example of how expenditures can be
DOLLARS
TODAY Planned expenditure
Actual expenditure
JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC FIGURE 3.8 Tracking planned
vs. actual expenditures.
monitored. By combining budget tracking with personnel tracking, you can use project management tools to determine the best resources for your limited budget.
3.2 PROJECT PERSONNEL
To determine the project schedule and estimate the associated effort and costs, we need to know approximately how many people will be working on the project, what tasks they will perform, and what abilities and experience they must have so they can do their jobs effectively. In this section, we look at how to decide who does what and how the staff can be organized.
Staff Roles and Characteristics
In Chapter 2, we examined several software process models, each depicting the way in which the several activities of software development are related. No matter the model, there are certain activities necessary to any software project. For example, every project requires people to interact with the customers to determine what they want and by when they want it. Other project personnel design the system, and still others write or test the programs. Key project activities are likely to include
1. requirements analysis 2. system design
3. program design
4. program implementation 5. testing
6. training 7. maintenance 8. quality assurance
However, not every task is performed by the same person or group; the assignment of staff to tasks depends on project size, staff expertise, and staff experience. There is great advantage in assigning different responsibilities to different sets of people, offering
“checks and balances” that can identify faults early in the development process. For example, suppose the test team is separate from those who design and code the system.
Testing new or modified software involves a system test, where the developers demon- strate to the customer that the system works as specified. The test team must define and document the way in which this test will be conducted and the criteria for linking the demonstrated functionality and performance characteristics to the requirements spec- ified by the customer. The test team can generate its test plan from the requirements documents without knowing how the internal pieces of the system are put together.
Because the test team has no preconceptions about how the hardware and software will work, it can concentrate on system functionality. This approach makes it easier for the test team to catch errors and omissions made by the designers or programmers. It is in part for this reason that the cleanroom method is organized to use an independent test team, as we will see in later chapters (Mills, Dyer, and Linger 1987).
Section 3.2 Project Personnel 95
For similar reasons, it is useful for program designers to be different from system designers. Program designers become deeply involved with the details of the code, and they sometimes neglect the larger picture of how the system should work. We will see in later chapters that techniques such as walkthroughs, inspections, and reviews can bring the two types of designers together to double-check the design before it goes on to be coded, as well as to provide continuity in the development process.
We saw in Chapter 1 that there are many other roles for personnel on the devel- opment or maintenance team. As we study each of the major tasks of development in subsequent chapters, we will describe the project team members who perform those tasks.
Once we have decided on the roles of project team members, we must decide which kinds of people we need in each role. Project personnel may differ in many ways, and it is not enough to say that a project needs an analyst, two designers, and five pro- grammers, for example. Two people with the same job title may differ in at least one of the following ways:
• ability to perform the work
• interest in the work
• experience with similar applications
• experience with similar tools or languages
• experience with similar techniques
• experience with similar development environment
• training
• ability to communicate with others
• ability to share responsibility with others
• management skills
Each of these characteristics can affect an individual’s ability to perform productively.
These variations help to explain why one programmer can write a particular routine in a day, whereas another requires a week. The differences can be critical, not only to schedule estimation, but also to the success of the project.
To understand each worker’s performance, we must know his or her ability to perform the work at hand. Some are good at viewing “the big picture,” but may not enjoy focusing on detail if asked to work on a small part of a large project. Such people may be better suited to system design or testing than to program design or coding.
Sometimes, ability is related to comfort. In classes or on projects, you may have worked with people who are more comfortable programming in one language than another.
Indeed, some developers feel more confident about their design abilities than their coding prowess. This feeling of comfort is important; people are usually more produc- tive when they have confidence in their ability to perform.
Interest in the work can also determine someone’s success on a project. Although very good at doing a particular job, an employee may be more interested in trying something new than in repeating something done many times before. Thus, the novelty of the work is sometimes a factor in generating interest in it. On the other hand, there are always people who prefer doing what they know and do best, rather than venturing
Two people 1 line of communication
Three people
Four people
Five people
3 lines of communication
6 lines of communication
10 lines of communication :n people
:
n(n-1)/2 lines of communication
FIGURE 3.9 Communication paths on a project.
into new territory. It is important that whoever is chosen for a task be excited about performing it, no matter what the reason.
Given equal ability and interest, two people may still differ in the amount of expe- rience or training they have had with similar applications, tools, or techniques. The per- son who has already been successful at using C to write a communications controller is more likely to write another communications controller in C faster (but not necessarily more clearly or efficiently) than someone who has neither experience with C nor knowl- edge of what a communications controller does. Thus, selection of project personnel involves not only individual ability and skill, but also experience and training.
On every software development or maintenance project, members of the devel- opment team communicate with one another, with users, and with the customer. The project’s progress is affected not only by the degree of communication, but also by the ability of individuals to communicate their ideas. Software failures can result from a breakdown in communication and understanding, so the number of people who need to communicate with one another can affect the quality of the resulting product. Figure 3.9 shows us how quickly the lines of communication can grow. Increasing a work team from two to three people triples the number of possible lines of communication. In gen- eral, if a project has nworkers, then there are pairs of people who might need to communicate, and possible teams that can be created to work on smaller pieces of the project. Thus, a project involving only 10 people can use 45 lines of communication, and there are 1023 possible committees or teams that can be formed to handle subsystem development!
Many projects involve several people who must share responsibility for complet- ing one or more activities. Those working on one aspect of project development must trust other team members to do their parts. In classes, you are usually in total control of the projects you do. You begin with the requirements (usually prescribed by your instructor), design a solution to the problem, outline the code, write the actual lines of code, and test the resulting programs. However, when working in a team, either in school or for an employer or customer, you must be able to share the workload. Not only does this require verbal communication of ideas and results, but it also requires written documentation of what you plan to do and what you have done. You must
2n - 1
n1n - 12>2
Section 3.2 Project Personnel 97
accept the results of others without redoing their work. Many people have difficulty in sharing control in this way.
Control is an issue in managing the project, too. Some people are good at direct- ing the work of others. This aspect of personnel interaction is also related to the com- fort people feel with the jobs they have. Those who feel uncomfortable with the idea of pushing their colleagues to stay on schedule, to document their code, or to meet with the customer are not good candidates for development jobs involving the management of other workers.
Thus, several aspects of a worker’s background can affect the quality of the project team. A project manager should know each person’s interests and abilities when choosing who will work together. Sidebar 3.1 explains how meetings and their organization can enhance or impede project progress. As we will see later in this chap- ter, employee background and communication can also have dramatic effects on the project’s cost and schedule.