CHANGES IN SOFTWARE
SIDEBAR 3.4 BOEHM’S TOP TEN RISK ITEMS
3.14 EXERCISES
1. You are about to bake a two-layer birthday cake with icing. Describe the cake-baking project as a work breakdown structure. Generate an activity graph from that structure.
What is the critical path?
2. Figure 3.23 is an activity graph for a software development project. The number corre- sponding to each edge of the graph indicates the number of days required to complete the activity represented by that branch. For example, it will take four days to complete the
Section 3.14 Exercises 139
activity that ends in milestone E. For each activity, list its precursors and compute the earliest start time, the latest start time, and the slack. Then, identify the critical path.
3. Figure 3.24 is an activity graph. Find the critical path.
E
C
G J
F H K
B I
D
START A FINISH
3
5 2
6
2
8
3 2
4
4 3 2
5
3 1
L 3
FIGURE 3.23 Activity graph for Exercise 2.
B
D
F J L
G I K
C E H
START A FINISH
5 2
3 1
2 2 4
2 4
3 6
3
2 5
3
FIGURE 3.24 Activity graph for Exercise 3.
4. On a software development project, what kinds of activities can be performed in parallel?
Explain why the activity graph sometimes hides the interdependencies of these activities.
5. Describe how adding personnel to a project that is behind schedule might make the project completion date even later.
6. A large government agency wants to contract with a software development firm for a project involving 20,000 lines of code. The Hardand Software Company uses Walston and Felix’s estimating technique for determining the number of people required for the time needed to write that much code. How many person-months does Hardand estimate will be needed? If the government’s estimate of size is 10% too low (i.e., 20,000 lines of code represent only 90% of the actual size), how many additional person-months will be needed? In general, if the government’s size estimate is k% too low, by how much must the person-month estimate change?
7. Explain why it takes longer to develop a utility program than an applications program and longer still to develop a system program.
8. Manny’s Manufacturing must decide whether to build or buy a software package to keep track of its inventory. Manny’s computer experts estimate that it will cost $325,000 to buy the necessary programs. To build the programs in-house, programmers will cost $5000 each per month. What factors should Manny consider in making his decision? When is it better to build? To buy?
9. Brooks says that adding people to a late project makes it even later (Brooks 1975). Some schedule-estimation techniques seem to indicate that adding people to a project can shorten development time. Is this a contradiction? Why or why not?
10. Many studies indicate that two of the major reasons that a project is late are changing requirements (called requirements volatility or instability) and employee turnover.
Review the cost models discussed in this chapter, plus any you may use on your job, and determine which models have cost factors that reflect the effects of these reasons.
11. Even on your student projects, there are significant risks to your finishing your project on time. Analyze a student software development project and list the risks. What is the risk exposure? What techniques can you use to mitigate each risk?
12. Many project managers plan their schedules based on programmer productivity on past projects. This productivity is often measured in terms of a unit of size per unit of time. For example, an organization may produce 300 lines of code per day or 1200 application points per month. Is it appropriate to measure productivity in this way? Discuss the mea- surement of productivity in terms of the following issues:
• Different languages can produce different numbers of lines of code for implementa- tion of the same design.
• Productivity in lines of code cannot be measured until implementation begins.
• Programmers may structure code to meet productivity goals.
In this chapter, we look at
• eliciting requirements from our customers
• modeling requirements
• reviewing requirements to ensure their quality
• documenting requirements for use by the design and test teams
Capturing the Requirements
4
141 In earlier chapters, when looking at various process models, we noted several key steps for successful software development. In particular, each proposed model of the software-development process includes activities aimed at capturing requirements:
understanding our customers’ fundamental problems and goals. Thus, our understand- ing of system intent and function starts with an examination of requirements. In this chapter, we look at the various types of requirements and their different sources, and we discuss how to resolve conflicting requirements. We detail a variety of modeling notations and requirements-specification methods, with examples of both automated and manual techniques. These models help us understand the requirements and docu- ment the relationships among them. Once the requirements are well understood, we learn how to review them for correctness and completeness. At the end of the chapter, we learn how to choose a requirements-specification method that is appropriate to the project under consideration, based on the project’s size, scope, and the criticality of its mission.
Analyzing requirements involves much more than merely writing down what the customer wants. As we shall see, we must find requirements on which both we and the customer can agree and on which we can build our test procedures. First, let us examine exactly what requirements are, why they are so important (see Sidebar 4.1), and how we work with users and customers to define and document them.