Statistical Software Engineering (1996) / Chapter Skim
Currently Skimming:
A Software Production Model
A Software Production Model
Pages 13-26
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 13... ...
and those adopting a more integrated, less linear, view of a process (e.g., the spiral model referred to in Chapter 6~. Although the discussion in this chapter is specific to a particular model, that in subsequent chapters cuts across all models and emphasizes the need to incorporate statistical insight into the measurement, data collection, and analysis aspects of software production.
|
From page 14... ...
Errors in requirements arise for a number of reasons, including ambiguous statements, inconsistent information, unclear user requirements, and incomplete requests. Projects that have ill-defined or unstated requirements are subject to constant iteration, and a lack of precise requirements is a key source of subsequent software faults.
|
From page 15... ...
of the number of issues is reduced to 53, implying that only a half dozen issues remain to be discovered in the document. ~ Other mismatches between the data arising in software review and those in capture-recapture wildlife population studies induce bias in the MLE.
|
From page 16... ...
25 3 4 13 9 6 1 1 1 2 1 1 3 1 2 1 1 l l 2 l l 60 application, it is necessary to verify that the "easy to find" and "hard to find" classification is meaningful, or to determine that it is merely partitioning the distribution of difficulty in an arbitrary manner. A relevant point in this and other applications of statistical methods in software engineering is that addressing aspects of the problem that induce study bias is important and valued—theoretical work addressing aspects of statistical bias is not likely to be as highly valued.
|
From page 17... ...
After document reviews and approvals, the coding may begin. Using private copies of the code, developers make the changes and add the files specified in the coding unit.
|
From page 18... ...
Specifically, the purpose of software testing is to detect errors in a program and, in the absence of errors, gain confidence in the correctness of the program or the system under test. Although testing is no substitute for improving a process, it does play a crucial role in the overall software development process.
|
From page 19... ...
as wet! as unstable, frequently changed cocte.
|
From page 21... ...
In black box testing, only knowledge of the functionality of the software is used for testing; knowledge of the detailed architectural structure or of the procedures used in coding is not used. White box testing is typically used during unit testing, in which the tester (who is usually the developer who created the code)
|
From page 22... ...
Even if this possibility can be discounted, questions remain about the efficiency of statistical operational profile testing, which can be very inefficient, because most often the system under test will be used in routine ways, and thus a randomly drawn sample will be highly weighted by routine operations. This high weighting may be fine if the number of test cases is very large.
|
From page 23... ...
Suppose we decide upon a sample of size 6. The corresponding Latin hyper cube design is easily constructed by dividing each variable into six equal probability intervals and sampling randomly from each interval.
|
From page 24... ...
For a statistical experiment intended to address only main effects, a highly fractionated factorial design would be sufficient. However, in the case of software testing, there is no statistical variability and little or no interest in estimating various effects.
|
From page 25... ...
, the difficulty with fault insertion is that the faults inserted ought to be subtle enough so that the system can be compiled and tested; no two inserted faults should interact with each other; and while it may be possible at the unit testing level, it is prohibitively expensive for integration testing. It should be pointed out that the use of capture-recapture sampling, outlined in this chapter's subsection titled "Design," for quantifying document reviews does not require fault seeding and, accordingly, is not subject to the above difficulties.
|
From page 26... ...
, and others, the key issue is to explicitly incorporate the economic trade-off between the decision to stop testing (and absorb the cost of fixing subsequent field faults) and the decision to continue testing (and incur ongoing costs to find and fix faults before release of a software product)
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.