Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
CHAPTER 31 This chapter: 31.1 ● Introduction Assessing methods ■ discusses the problem of assessing tools and methods ■ reviews current techniques ■ examines the evidence about verification techniques ■ suggests that there is no single best method ■ discusses the challenges of introducing new methods. We saw in Chapter 1 that there are usually a number of objectives to be met in the construction of a piece of software. A major goal used to be high performance (speed and size), but with improved hardware cost and performance, this issue has declined in importance. Nowadays factors like software costs, reliability and ease of maintenance are increasingly important. For any particular project, it is, of course, vital to assess carefully what the specific aims are. Having done this, we will usually find that some of them are mutually contradictory, so that we have to decide upon a blend or compromise of objectives. This book has described a variety of techniques for software construction. All of the techniques attempt in some way to improve the process of software development and to meet the various goals of software development projects. The purpose of this chapter is to see how we can assess methods and choose a collection of methods that are appropriate for a particular project.
386 Chapter 31 ■ Assessing methods 31.2 ● How to assess methods Is it possible to identify a collection of tools and methods that are ideal in all circumstances? The answer is no. Software engineering is at an exciting time. There are a dozen schools of thought competing to demonstrate their supremacy and no single package of tools and methods seems set to succeed. Some methods seem particularly successful in specific areas, for example, the data structure design method in information systems. Other methods, like structured walkthroughs, seem generally useful. In the field of programming languages, declarative languages have become important in expert systems, while highly modular imperative languages are widely used in real-time and command and control systems. Ideally, metrics (Chapter 29) would enable us to determine the best method or combination of software development methods. Regrettably, this is virtually impossible. The first problem is identifying the criteria for a best method. As we saw in Chapter 1 on problems and prospects, there are usually a number of goals for any software development project. In order to choose between methods it is necessary to establish what blend of criteria is appropriate for the particular project. For example, the set of goals for a particular project might be to optimize: ■ development effort, ■ reliability, and ■ maintainability and these are in conflict with each other. In general, the most significant conflict is probably between development effort and reliability of the product. For example, a safety-critical system needs to be highly reliable. However, for a one-off program for a user to extract information from a database, the prime goal may be quick delivery. There can be no set of factors that allow universal comparison between methods. Equally, it is unlikely that there will ever be a single best method. Suppose that we had narrowed down the choice to two applicable methods, called A and B. What we would like to have is hard evidence like this: “Method A gives 25% better productivity than method B.” Regrettably, there is no such data available today, because of the enormous difficulty of creating it. Let us examine some of those difficulties. Because of cost, it is virtually impossible to conduct any realistic experiments in which two or more methods are compared. (The cost of developing the same piece of software twice is usually prohibitive.) Usually the only experimental evidence is based on scaled-down experiments. Suppose, for example, that we wanted to compare two design methods, A and B. We could give ten people the specification of a small system and ask them to use method A, and similarly we could ask a second group to use method B. We could measure the average time taken to complete the designs and hence hope to compare the productivities of the methods. We could go on to assign additional problems and employ more people to increase our confidence in the results. Ultimately, we might gain some confidence about the relative productivity of the two methods. But many criticisms can be aimed at experiments like these. Are the backgrounds of the participants equal? Is the experience of the participants typical? (Often students are used in experiments, because they are cheap and plentifully available. But are students typical of professional software developers?) Have sufficient number of people taken
- Page 356 and 357: 26.3 Extreme programming 333 develo
- Page 358 and 359: SELF-TEST QUESTION 26.3 Which of th
- Page 360 and 361: CHAPTER 27 This chapter explains:
- Page 362 and 363: Figure 27.1 The phases of the unifi
- Page 364 and 365: 27.5 ● Iteration 27.6 Case study
- Page 366 and 367: The transition phase Summary 343 Th
- Page 368: PART F PROJECT MANAGEMENT
- Page 371 and 372: 348 Chapter 28 ■ Teams The commun
- Page 373 and 374: 350 Chapter 28 ■ Teams Level of s
- Page 375 and 376: 352 Chapter 28 ■ Teams A chief pr
- Page 377 and 378: 354 Chapter 28 ■ Teams benefits o
- Page 379 and 380: 356 Chapter 28 ■ Teams • Furthe
- Page 381 and 382: 358 Chapter 29 ■ Software metrics
- Page 383 and 384: 360 Chapter 29 ■ Software metrics
- Page 385 and 386: 362 Chapter 29 ■ Software metrics
- Page 387 and 388: 364 Chapter 29 ■ Software metrics
- Page 389 and 390: 366 Chapter 29 ■ Software metrics
- Page 391 and 392: 368 Chapter 29 ■ Software metrics
- Page 393 and 394: CHAPTER 30 This chapter: 30.1 ● I
- Page 395 and 396: 372 Chapter 30 ■ Project manageme
- Page 397 and 398: 374 Chapter 30 ■ Project manageme
- Page 399 and 400: 376 Chapter 30 ■ Project manageme
- Page 401 and 402: 378 Chapter 30 ■ Project manageme
- Page 403 and 404: 380 Chapter 30 ■ Project manageme
- Page 405 and 406: 382 Chapter 30 ■ Project manageme
- Page 410 and 411: 31.3 Case study - assessing verific
- Page 412 and 413: 31.5 A single development method? 3
- Page 414 and 415: Further reading 391 31.2 Draw up a
- Page 416 and 417: 32.3 ● The world of programming l
- Page 418 and 419: 32.5 ● The real world of software
- Page 420 and 421: 32.6 Control versus skill 397 Final
- Page 422 and 423: Formal methods 32.7 Future methods
- Page 424 and 425: Summary 401 In the short-term futur
- Page 426: Further reading 403 An extensive tr
- Page 430 and 431: APPENDIX A Case studies are used th
- Page 432 and 433: Figure A.1 Cyberspace invaders A.4
- Page 434 and 435: APPENDIX B Glossary Within the fiel
- Page 436 and 437: C.2 ● Class diagrams C.2 Class di
- Page 438 and 439: util Figure C.6 A package diagram S
- Page 440 and 441: References to books and websites ar
- Page 442 and 443: abstraction 99, 107 acceptance test
- Page 444 and 445: fork 324 formal methods 276, 388, 3
- Page 446 and 447: quality 18, 362 quality assurance 1
CHAPTER<br />
31<br />
This chapter:<br />
31.1 ● Introduction<br />
Assessing methods<br />
■ discusses the problem of assessing tools and methods<br />
■ reviews current techniques<br />
■ examines the evidence about verification techniques<br />
■ suggests that there is no single best method<br />
■ discusses the challenges of introducing new methods.<br />
We saw in Chapter 1 that there are usually a number of objectives to be met in the construction<br />
of a piece of software. A major goal used to be high per<strong>for</strong>mance (speed and<br />
size), but with improved hardware cost and per<strong>for</strong>mance, this issue has declined in<br />
importance. Nowadays factors like software costs, reliability and ease of maintenance<br />
are increasingly important. For any particular project, it is, of course, vital to assess carefully<br />
what the specific aims are. Having done this, we will usually find that some of them<br />
are mutually contradictory, so that we have to decide upon a blend or compromise of<br />
objectives.<br />
This book has described a variety of techniques <strong>for</strong> software construction. All of the<br />
techniques attempt in some way to improve the process of software development and<br />
to meet the various goals of software development projects. The purpose of this chapter<br />
is to see how we can assess methods and choose a collection of methods that are<br />
appropriate <strong>for</strong> a particular project.
Change language