Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
29.5 Software quality 363 encompass the complete range of attributes associated with software, except the cost of construction. ■ correctness – the extent to which the software meets its specification and meets its users’ requirements ■ reliability – the degree to which the software continues to work without failing ■ performance – the amount of main memory and processor time that the software uses ■ integrity – the degree to which the software enforces control over access to information by users ■ usability – the ease of use of the software ■ maintainability – the effort required to find and fix a fault ■ flexibility – the effort required to change the software to meet changed requirements ■ testability – the effort required to test the software effectively ■ portability – the effort required to transfer the software to a different hardware and/or software platform ■ reusability – the extent to which the software (or a component within it) can be reused within some other software ■ interoperability – the effort required to make the software work in conjunction with some other software ■ security – the extent to which the software is safe from external sabotage that may damage it and impair its use. These attributes are related to the set of goals discussed in Chapter 1. As we saw, some of these qualities can be mutually contradictory, for example, if high performance is required, portability will probably suffer. Also, not every attribute is desired in every piece of software. So for each project it is important to identify the salient factors before development starts. SELF-TEST QUESTION 29.2 Software is to be developed to control a fly-by-wire airplane. What are likely to be the important factors? This list of quality factors can be used in one or more of the following situations: 1. at the outset of a software development, to clarify the goals 2. during development, to guide the development process towards the goals 3. on completion, to assess the completed piece of software. The above quality attributes are, of course, only qualitative (rather than quantitative) measures. And as we have seen earlier in this chapter, the purpose of metrics is to quantify desirable or interesting qualities. Thus a complexity measure, such as McCabe’s, can
364 Chapter 29 ■ Software metrics and quality assurance be used to measure maintainability. Reliability can be measured as MTTF. However, for many of these attributes, it is extremely difficult to make an accurate judgment and a subjective guess must suffice – with all its uncertainties. SELF-TEST QUESTION 29.3 List some other quality factors that can be quantified. 29.6 ● Quality assurance Quality assurance means ensuring that a software system meets its quality goals. The goals differ from one project to another. They must be clear and can be selected from the list of quality factors we saw earlier. To achieve its goals, a project must use effective tools and methods. Also checks must be carried out during the development process at every available opportunity to see that the process is being carried out correctly. To ensure that effective tools and methods are being used, an organization distills its best practices and documents them in a quality manual. This is like a library of all the effective tools, methods and notations. It is like a recipe book in cooking, except that it contains only the very best recipes. This manual describes all the standards and procedures that are available to be used. A standard defines a range, limit, tolerance or norm of some measurable attribute against which compliance can be judged. For example, during white box testing, every source code statement must be executed at least once. In the kitchen, all peeled potatoes must be inspected to ensure there is no skin remaining on them. A procedure prescribes a way of doing something (rules, steps, guidelines, plans). For example, black box testing, white box testing and a walkthrough must be used to verify each component of software. In the kitchen, all green vegetables will be steamed, rather than boiled. To be effective, quality assurance must be planned in advance – along with the planning of all other aspects of a software project. The project manager: 1. decides which quality factors are important for the particular project (e.g. high reliability and maintainability). In preparing a family meal, perhaps flavor and nutritional value are the paramount goals. 2. selects standards and procedures from the quality manual that are appropriate to meeting the quality goals (e.g. the use of complexity metrics to check maintainability). If the meal does not involve potatoes, then those parts of the quality manual that deal with potatoes can be omitted. 3. assembles these into a quality assurance plan for the project. This describes what the procedures and standards are, when they will be done, and who does them. More and more the organizations that produce software are having to convince their customers that they are using effective methods. More and more commonly they must
- Page 336 and 337: Answers to self-test questions 313
- Page 338 and 339: 24.2 ● Big-bang implementation 24
- Page 340 and 341: Tested component Figure 24.1 Top-do
- Page 342 and 343: 24.7 ● Use case driven implementa
- Page 344 and 345: ■ middle-out ■ use case based.
- Page 346 and 347: SELF-TEST QUESTION 25.1 What is the
- Page 348 and 349: sharing of software or their own re
- Page 350 and 351: Summary 327 Inappropriate patches,
- Page 352 and 353: Further reading 329 Cathedral and t
- Page 354 and 355: These are qualified by the statemen
- 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: 362 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 408 and 409: CHAPTER 31 This chapter: 31.1 ● I
- 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
364 Chapter 29 ■ <strong>Software</strong> metrics and quality assurance<br />
be used to measure maintainability. Reliability can be measured as MTTF. However, <strong>for</strong><br />
many of these attributes, it is extremely difficult to make an accurate judgment and a<br />
subjective guess must suffice – with all its uncertainties.<br />
SELF-TEST QUESTION<br />
29.3 List some other quality factors that can be quantified.<br />
29.6 ● Quality assurance<br />
Quality assurance means ensuring that a software system meets its quality goals. The<br />
goals differ from one project to another. They must be clear and can be selected from<br />
the list of quality factors we saw earlier. To achieve its goals, a project must use effective<br />
tools and methods. Also checks must be carried out during the development process at<br />
every available opportunity to see that the process is being carried out correctly.<br />
To ensure that effective tools and methods are being used, an organization distills its<br />
best practices and documents them in a quality manual. This is like a library of all the<br />
effective tools, methods and notations. It is like a recipe book in cooking, except that<br />
it contains only the very best recipes. This manual describes all the standards and procedures<br />
that are available to be used.<br />
A standard defines a range, limit, tolerance or norm of some measurable attribute<br />
against which compliance can be judged. For example, during white box testing, every<br />
source code statement must be executed at least once. In the kitchen, all peeled potatoes<br />
must be inspected to ensure there is no skin remaining on them.<br />
A procedure prescribes a way of doing something (rules, steps, guidelines, plans). For<br />
example, black box testing, white box testing and a walkthrough must be used to verify<br />
each component of software. In the kitchen, all green vegetables will be steamed,<br />
rather than boiled.<br />
To be effective, quality assurance must be planned in advance – along with the planning<br />
of all other aspects of a software project. The project manager:<br />
1. decides which quality factors are important <strong>for</strong> the particular project (e.g. high reliability<br />
and maintainability). In preparing a family meal, perhaps flavor and nutritional<br />
value are the paramount goals.<br />
2. selects standards and procedures from the quality manual that are appropriate to<br />
meeting the quality goals (e.g. the use of complexity metrics to check maintainability).<br />
If the meal does not involve potatoes, then those parts of the quality manual<br />
that deal with potatoes can be omitted.<br />
3. assembles these into a quality assurance plan <strong>for</strong> the project. This describes what<br />
the procedures and standards are, when they will be done, and who does them.<br />
More and more the organizations that produce software are having to convince their<br />
customers that they are using effective methods. More and more commonly they must