V. R. Basili, R. W. Selby, and D. H. Hutchens. Experimentation in software engineering. IEEE Transactions in Software Engineering, 12(7):733--743, 1986. 21  Home/Search   Document Not in Database   Summary   Related Articles   Check

....the Internet with representative network connections. Such a setting is very difficult to achieve and still leaves open the question whether it is representative. The experience with case studies of similar size and environment has shown that it is frequently not possible to generalize the results [10, 18, 20, 86, 93, 134]. In such a situation the usual alternative is simulation. But simulation is not effective either, because the results cannot be realistic. For example, no authoritative standards for simulating user or application behavior exist and it is difficult to separate the computational components from ....

V. R. Basili, R. W. Selby, and D. H. Hutchens. Experimentation in Software Engineering. IEEE Transactions on Software Engineering, 12(7):733--43, July 1986.

....components (classes and methods in Java API libraries) they knew. Our experiments adopted both the multi project variation approach, in which one subject conducted two or three different projects, and the replicated project approach, in which one project is conducted by two or more subjects [2]. Twelve experiments were conducted. In each experiment, the subject was asked to implement a predetermined task. Each task could be implemented with different combinations of components from the repository. The following is a sample task: Traditionally, Chinese write numbers with a comma ....

Basili, V.R., Selby, R.W., and Hutchen, D.H.: Experimentation in software engineering. IEEE Transactions on Software Engineering, 12(7):733-743, 1986.

....the constraints of software engineering. Constraints are, for example, the expense and difficulty of getting individual data points, the large amounts of variation in results due to human subjects, and the effects on studies due to various development paradigms in which the results must hold [5]. Evaluations of particular technologies have been undertaken to great effect, and have been useful for showing the feasibility or effectiveness of specific technologies in specific contexts. For example, Basili and Reiter [6] showed the benefits of a disciplined development methodology over ad ....

Victor R. Basili, Richard Selby and David Hutchens, Experimentation in Software Engineering, IEEE Transactions on Software Engineering, July 1986.

....software development because it rarely seems worth giving up the simplicity of treating thinking and acting as being interchangeable. the tasks are elicited during a task analysis [77,657] sometimes they are a result of process modeling or description (e.g. Tzerpos et al. 647] Basili et al. [34]) In SE there are many examples of process and task models. One of the most obvious characteristics of such models is their wide variability in granularity, form, and content. A classic process model is the so called waterfall software development process [613] which consists of a sequence of ....

....development process [613] which consists of a sequence of highlevel tasks to perform. In contrast, there are many fine grained models of program comprehension, both descriptive, like Sengler s pseudocode model of program comprehension [572] and normative, like Basili and Mill s process model [34] for bottom up comprehension of code. Other task models of programming [499] maintenance [664] remodularization [64] and reverse engineering [641] testify to the diversity of process and task modeling in the field. Similar types of task decompositions exist in other domains like reading ....

Basili, V. R., and Mills, H. D. Understanding and documenting programs. IEEE Transactions on Software Engineering, SE-8(3), May 1982, pp. 270--283.

....[9] as the subject of our case study, for several reasons. It features all three choices of stopping criteria. It features three interval shrinkage methods: bisection, secant, and inverse quadratic interpolation. A variation of it was used in an influential case study by Basili and Mills [2]. This allows us to more closely compare our work with theirs, as described in Section 6. As a consequence of the number of variations, the code is complex and difficult to follow, making it a good candidate for reverse engineering. 3.3 Algebraic specification We have chosen algebraic ....

....work. 6 Related work We are not aware of any other work concerning the adequacy of reverse engineering representations. However, several other groups have explored the use of formal methods to support reverse engineering. Perhaps the work most closely related to ours is that of Basili and Mills [2] in which they examine a program called ZEROIN, a Fortran implementation of ZBRENT. Basili and Mills are interested in applying ideas from structured programming and program correctness proofs to the understanding and annotation of computer programs. In particular, they construct a primeprogram ....

Victor R. Basili and Harlan D. Mills. Understanding and Documenting Programs. IEEE Transactions on Software Engineering, SE-8(3):270-283, (May 1982).

....focus. Research methods. A key aspect is the research methods used. We do not believe that we can continue to present new methods without being able to have some empirical evidence. Thus, we need to use empirical methods in our software engineering research, which means that experimentation [3] and case studies [4] are essential to succeed. Experimentation is important as it provides a better understanding of the methods investigated, and it also works as an important step before it is possible to transfer any research results for broader use. Case studies are an important tool to ....

Basili, V., Selby, R. W. and Hutchens, D. H., Experimentation in Software Engineering, IEEE Transactions on Software Engineering, Vol. 12, No. 7, pp. 733-743, 1986.

....and C. 6 RELATED WORK We are not aware of any other work concerning the adequacy of reverse engineering representations. However, several other groups have explored the use of formal methods to support reverse engineering. Perhaps the work most closely related to ours is that of Basili and Mills [2] in which they examine a program called ZEROIN, a Fortran implementation of ZBRENT. Basili and Mills are interested in applying ideas from structured programming and program correctness proofs to the understanding and annotation of computer programs. In particular, they construct a primeprogram ....

Victor R. Basili and Harlan D. Mills. Understanding and Documenting Programs. IEEE Transactions on Software Engineering, SE-8(3):270-283, (May 1982).

....e#ectiveness [14] We measure the e#ectiveness of a testing technique in terms of its ability to detect certain types of faults; we also measure the e#ectiveness of a testing technique relative to the e#ectiveness of other testing techniques. Although there have been studies of fault categories [4, 11, 18, 22], there is no established correlation between categories of faults and testing techniques that expose those faults. Furthermore, although there have been formal and empirical studies [4, 17, 18, 30] on the relative e#ectiveness of testing techniques, there is no conclusive evidence that one ....

....the e#ectiveness of other testing techniques. Although there have been studies of fault categories [4, 11, 18, 22] there is no established correlation between categories of faults and testing techniques that expose those faults. Furthermore, although there have been formal and empirical studies [4, 17, 18, 30] on the relative e#ectiveness of testing techniques, there is no conclusive evidence that one testing technique is superior in fault detection ability. Performing studies on fault detection is di#cult because of the lack of fault seeding techniques that automatically and systematically insert ....

[Article contains additional citation context not shown here]

V. R. Basili and R. W. Selby. Comparing the e#ectiveness of software testing strategies. IEEE Transactions on Software Engineering, 13(12), December 1987.

....between branch coverage and fault detection is at least as strong. However, any form of structural testing has a limited e ectiveness at fault detection. Even when testing with a criterion of 100 coverage, structural testing is not likely to reveal more than half of the faults in a body of code [BS87] [GW86] Sel86] Additionally, high code coverage can be a very expensive goal. 100 code coverage may not be feasible outside of unit test for a number of factors including code handling impossible error conditions, dead code, hooks for new functionality, and code requiring special hardware. ....

.... operator or a statement wrongly placed in a logical expression [GW86] A third study showed statement coverage to be more e ective at detecting faults of involving the wrong operation than faults involving a missing operation, and weakest at detecting cosmetic, interface, and data faults [BS87]. Therefore, we decided to examine a large, industrial software product and the testing that is performed on it. By looking at errors reported from the eld, and whether or not their underlying faults had been covered in testing, we have acquired a snapshot of the faults that slip by branch ....

V. Basili and R. Selby. Comparing the eectiveness of software testing strategies. IEEE Transactions of Software Engineering, SE13 (12):1278-1296, December 1987.

....to improve software quality shows that formal technical review (FTR) provides unique and important benefits. Some studies provide evidence that FTR can be more effective at discovering errors than testing, while others indicate that it can discover different classes of errors than testing [19, 4]. In concert with other process improvements, Fujitsu found FTR to be so effective at discovering errors that they dropped system testing from their software development procedure [2] FTR forms an essential part of methods and models for very high quality software, such as Cleanroom Software ....

V.R. Basili, R.W. Selby, and D.H. Hutchins. Experimentation in software engineering. IEEE Transactions on Software Engineering, SE-12(7):733--743, July 1986.

No context found.

V. R. Basili, R. W. Selby, and D. H. Hutchens. Experimentation in software engineering. IEEE Transactions in Software Engineering, 12(7):733--743, 1986. 21

No context found.

Victor R. Basili, Richard W. Selby, and David H. Hutchens. Experimentation in software engineering. IEEE Transactions on Software Engineering, SE-12(7):733--743, July 1986.

No context found.

Victor R. Basili, Richard W. Selby, David H. Hutchens, Experimentation in Software Engineering, IEEE Transactions on Software Engineering, Vol. Se-12 (1986), no.7, 733--743.

.... needs to be top down or goaloriented; objectives determine the choice of metrics [10] Various goal oriented measurement approaches exist, including Murine and McCall s SQM [22] Akao s QFD [23] and Basili s G Q M [10, 11] Empirical research studies need to be based on sound principles [24]. Process measurement requires an explicit model of the process object to be measured [6, 9] Process data are owned by individuals and only explicitly released for well specified purposes. A comprehensive state of the art review of measurement and empirical research appears in [16] 3.2.1 ....

Victor R. Basili, Richard W. Selby, and David H. Hutchens. Experimentation in software engineering. IEEE Transactions on Software Engineering, SE-12(7):733--743, July 1986.

....such as finite state machines and object orientation, but no experience with the particular languages or CASE tools. The students worked together in teams of 2 or 3 students. Design. The RSLs were examined in a replicated project scope according to Basili s classification of experimental scopes [BSH86]. This means that each team performed the same task, the development of a requirements model based on a set of informal requirements, but using a different RSL. Six teams were formed such that there is a one to one relation between team and RSL. This design was a compromise, because the effort per ....

V.R. Basili, R.W. Selby, and D.H. Hutchens. Experimentation in software engineering. IEEE Transactions on Software Engineering, SE-12(7):733--743, July 1986.

....made to SE. This paper seeks to highlight the need for an empirical validation of all artifacts used in SE, and then proposes an approach to introduce this based on experimental design techniques, widely used in other fields of science and engineering. Other researchers, including Basili [Basili, 86] and Pfleeger [Pfleeger, 95] have published work on experimental design and SE. In this paper, we aim to address in detail particular points, such as the parameters to be controlled in a SE experiment, and will set out several examples of how different types of experimental design can be applied ....

V.R. Basili, R.W. Selby, D.H. Hutchens. Experimentation in Software Engineering. IEEE Transactions on Software Engineering, vol. 12 (7), July 1986, pp. 733-743.

....the collected data . How shall I deal with tools, methods and processes in order to make the measurement automatic This set of questions makes us wish to build a meta system that facilitates the configuration of several measurement programs. 2 Software Measurement Problems Among many others [BSH86] BMB96] FPG94] have called the attention to the lack of experimental evidence to confirm the benefit of the new methods, techniques, tools and processes, which are proposed by various research and development groups, and by organizations that commercialize tools or training. It is thus ....

V.R.Basili, R.W. Selby, and D.H.Hutchens. Experimentation in Software Engineering. IEEE Transactions on Software Engineering, 12(6), 1986.

No context found.

V. R. Basili, R. Selby, and D. Hutchens, Experimentation in software engineering, IEEE Transactions on Software Engineering, 12(7), pp. 733-743, 1986.

No context found.

V. R. Basili and H. D. Mills, Understanding and Documenting Programs, IEEE Transactions on Software Engineering, 8(3), pp. 270-283, 1982.

No context found.

Victor R. Basili, Richard W. Selby, and David H. Hutchens. Experimentation in software engineering. IEEE Transactions on Software Engineering, SE-12(7):733--743, July 1986.

No context found.

Basili, V., Selby, R., and D. Hutchens. Experimentation in Software Engineering. IEEE Transactions on Software Engineering, Vol. SE-12, No. 47 July 1986, pp. 733-743.

No context found.

Victor Basili, Richard Selby, and David Hutchens. Experimentation in Software Engineering. IEEE Transactions on Software Engineering, SE-12(7):733--743, July 1986.

No context found.

Basili, V.R., Selby R.W. and Hutchens D.H. Experimentation in Software Engineering. IEEE Transactions on Software Engineering, SE-12,7 (1986), 733-743.

No context found.

V. Basili, D. Hutchens, An Empirical Study of a Complexity Family, IEEE Transactions on Software Engineering, Volume 9, No. 6, November 1983, pp. 664-672

No context found.

Basili, V. R., Welby, R. W., Hutchens, D. H. Experimentation in Software Engineering. IEEE Transactions on Software Engineering. 12(7):733-743, July 1986.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC