• No results found

Measure Twice, Cut Once:

Upstream Prerequisites

3 Contents 4 3.1 Importance of Prerequisites 5

3.2 Determine the Kind of Software You’re Working On

6 3.3 Problem-Definition Prerequisite 7 3.4 Requirements Prerequisite 8 3.5 Architecture Prerequisite 9

3.6 Amount of Time to Spend on Upstream Prerequisites

10

Related Topics

11

Key construction decisions: Chapter 4

12

Effect of project size on construction and prerequisites: Chapter 27

13

Relationship between quality goals and construction activities: Chapter 20

14

Managing construction: Chapter 28

15

Design: Chapter 5

16

Before beginning construction of a house, a builder reviews blueprints, checks

17

that all permits have been obtained, and surveys the house’s foundation. A

18

builder prepares for building a skyscraper one way, a housing development a

19

different way, and a doghouse a third way. No matter what the project, the prepa-

20

ration is tailored to the project’s specific needs and done conscientiously before

21

construction begins.

22

This chapter describes the work that must be done to prepare for software con-

23

struction. As with building construction, much of the success or failure of the

24

project has already been determined before construction begins. If the foundation

25

hasn’t been laid well or the planning is inadequate, the best you can do during

26

construction is to keep damage to a minimum. If you want to create a polished

27

jewel, you have to start with a diamond in the rough. If you start with plans for a

28

brick, the best you can create is a fancy brick.

29

“Measure twice, cut once” is highly relevant to the construction part of software

30

development, which can account for as much as 65 percent of the total project

31

costs. The worst software projects end up doing construction two or three times

32

or more. Doing the most expensive part of the project twice is as bad an idea in

33

software as it is in any other line of work.

34

Although this chapter lays the groundwork for successful software construction,

35

it doesn’t discuss construction directly. If you’re feeling carnivorous or you’re

36

already well versed in the software-engineering life cycle, look for the construc-

37

tion meat beginning in Chapter 5. If you don’t like the idea of prerequisites to

38

construction, review Section 3.2, “Determine the Kind of Software You’re

39

Working On,” to see how prerequisites apply to your situation, and then take a

40

look at the data in Section 3.1 which describes the cost of not doing prerequi-

41

sites.

42

3.1 Importance of Prerequisites

43

A common denominator of programmers who build high-quality software is their

44

use of high-quality practices. Such practices emphasize quality at the beginning,

45

middle, and end of a project.

46

If you emphasize quality at the end of a project, you emphasize system testing.

47

Testing is what many people think of when they think of software quality assur-

48

ance. Testing, however, is only one part of a complete quality-assurance strat-

49

egy, and it’s not the most influential part. Testing can’t detect a flaw such as

50

building the wrong product or building the right product in the wrong way. Such

51

flaws must be worked out earlier than in testing—before construction begins.

52

If you emphasize quality in the middle of the project, you emphasize construc-

53

tion practices. Such practices are the focus of most of this book.

54

If you emphasize quality at the beginning of the project, you plan for, require,

55

and design a high-quality product. If you start the process with designs for a

56

Pontiac Aztek, you can test it all you want to, and it will never turn into a Rolls-

57

Royce. You might build the best possible Aztek, but if you want a Rolls-Royce,

58

you have to plan from the beginning to build one. In software development, you

59

do such planning when you define the problem, when you specify the solution,

60

and when you design the solution.

61

CROSS-REFERENCE Pay-

ing attention to quality is also the best way to improve pro- ductivity. For details, see Section 20.5, “The General Principle of Software Qual- ity.”

Since construction is in the middle of a software project, by the time you get to

62

construction, the earlier parts of the project have already laid some of the

63

groundwork for success or failure. During construction, however, you should at

64

least be able to determine how good your situation is and to back up if you see

65

the black clouds of failure looming on the horizon. The rest of this chapter de-

66

scribes in detail why proper preparation is important and tells you how to deter-

67

mine whether you’re really ready to begin construction.

68

Do Prerequisites Apply to Modern Software Pro-