Statistical Software Engineering (1996) / Chapter Skim
Currently Skimming:
Critique of Some Current Applications of Statistics in Software Engineering
Critique of Some Current Applications of Statistics in Software Engineering
Pages 27-42
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 27... ...
The maturity of an organization's process changes the granularity of the data that can be used effectively in project cost estimation; 4. The reliability of inputs to cost estimation models varies widely; and Managers attempt to manage to the estimates, reducing the validity of historical data as a basis for validation.
|
From page 28... ...
1.049 0.1250 8.397 RMS 0.194 These fitted coefficients suggest that development effort is proportional to product size; a formal test of the hypothesis, H: ,B = 1, gives a t value at the .65 significance level. The estimated intercept after fixing ,B = 1 is 1.24; the resulting fit and a 95% prediction interval are overlaid on the data in Figure 3.
|
From page 29... ...
. Because of the lack of statistical rigor in most cost estimation models, software development organizations usually handcraft weighting schemes to fit their historical results.
|
From page 30... ...
Process Volatility In immature software development organizations, the processes used differ across projects because they are based on the experiences and preferences of the individuals assigned to each project, rather than on common organizational practice. Thus, in such organizations cost estimation models must attempt to predict the results of a process that varies widely across projects.
|
From page 31... ...
To aid in identifying the potential risks in a software development project, it would also be beneficial to have reliable confidence bounds for different components of the estimated size or effort. Statistical methods can be applied to develop prior probabilities (e.g., for Bayesian estimation models)
|
From page 32... ...
. 0~ tne models take as Input either failure time or failure count data and fit a stochastic process model to reflect reliability growth.
|
From page 33... ...
Although such work is of some interest, the pane} does not believe that it merits extensive research by the statistical community, but thinks rather that statistical research could be directed more fruitfully to providing insight to the users of the models that currently exist. The problem is validation of such models with respect to a particular data source, to allow users to decide which, if any, prediction scheme is producing accurate results for the actual software failure process under examination.
|
From page 34... ...
. Observed and fitted cumulative faults versus staff time (bottom)
|
From page 35... ...
, cumulative staff time (days) , and cumulative faults for a large telecommunications system on 198 consecutive calendar days (with duplicate lines representing weekends or holidays)
|
From page 36... ...
Influence of the Development Process on Software Dependability As noted above, surprisingly little use has been made of explanatory variable models, such as proportional hazards regression, in the modeling of software dependability. A major reason, the panel believes, is the difficulty that software engineers have in identifying variables that can 36
|
From page 37... ...
A further problem is that the observable in this software development application is a realization of a stochastic process, and not merely of a lifetime random variable. Thus there seems to be an opportunity for research into models that, on the one hand, capture current understanding of the nature of the growth in reliability that takes place as a result of debugging and, on the other hand, allow input about the nature of the development process or the architecture of the product.
|
From page 38... ...
that, in the presence of design faults, one cannot simply assume that different versions will fail independently of one another. Thus the simple hardware reliability models that involve mere redundancy, and assume independence of component failures, cannot be used.
|
From page 39... ...
There is evidence that human judgment, even in "hard" sciences such as physics, can be seriously in error (Henr~on and Fischhoff, ~ 986~: people seem to make consistent errors and tend to be optimistic in their own judgment regarding their likely error. It is likely that software engineering judgments are similarly fallible, and so this area calls for some statistical experimentation.
|
From page 40... ...
Experimentation, Data Collection, and General Statistical Techniques A dearth of data has been a problem in much of safety-critical software engineering since its inception. Only a handful of published data sets exists even for the software reliability growth problem, which is by far the most extensively developed aspect of software dependability assessment.
|
From page 41... ...
and aspects of the software production process such as software reuse, especially in systems employing object-oriented languages. The most widely used code metric, the NCSL (noncommentary source line)
|
From page 42... ...
provide one way to assess variable redundancy and the effect on fitted models, but other approaches that use judgment composites, or composites based on other bodies of data (Tukey, 1991) , will often be more effective than discarding metrics.
|
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.