H. D. Mills, M. Dyer, and R. C. Linger. Cleanroom software engineering. IEEE Software, pages 19--24, September 1987.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....use by other flows. However, a new approach to flow semantics permits flows themselves to be deterministic, despite the underlying asynchronous behavior of their constituent services. The basic FSQ semantic model of Flow Structures is the well known functional model [Hoffman 2001, Mills 1986, Mills 2002, Prowell 1999] that treats programs as rules for mathematical functions, that is, mappings from domains (inputs, stimuli) to ranges (outputs, responses) This model can be extended to a new semantics that permits flows to be defined as deterministic entities, no matter what changing or ....

....complete understanding of expressions is achievable and essential in other mathematical disciplines, but it remains an elusive goal in software today. Program behavior abstraction can be accomplished through the function theoretic mathematics and methods [Hausler 1990, Hoffman 2001, Mills 1986, Mills 2002, Parnas 1994, Pleszkoch 1990, Prowell 1999] that have been previously applied to the development of FSQ engineering concepts in this project. As noted, programs are compact representations of very large sets of possible behaviors. The process of deriving and expressing the net functional effect ....

Mills, H. & Linger, R. "Cleanroom Software Engineering." Encyclopedia of Software Engineering, 2nd ed. New York, NY: John Wiley & Sons, Inc., 2002.

....what caused the effects. It should be noted that there are a number of different improvement paradigms that are quite different from the three that have been presented and discussed here. There are improvement paradigms covering the entire range from low level focused efforts such as Cleanroom (Mills, 1987) to general approaches covering an entire organization, e.g. Total Quality Management (Gillies, 1992) While relevant, they have not been discussed here because this chapter has not been intended to be an exhaustive discussion of the state of the art within software process improvement. The ....

Harlan D. Mills, Michael Dyer and Richard Linger. Cleanroom Software Engineering. IEEE Software, September 1987. 249

....failures; ii) transient failures or whose consequences are not serious to the users needs are of little practical importance in the operational use of the software. In some programs, empirical analysis find that removing 60 of product defects would only led to a 3 reliability improvement [16]. Curiously, these are good results for classical SE. On the one hand, not all software faults imply less system reliability (if the probability of choosing an input which causes an erratic output is low) On the other hand, dysfunctional and annoying software failures can ultimately be detected ....

Mills D., Dyer M. and Linger R. (1987). Cleanroom software engineering, In: IEEE Software, vol.4, no.2.

....18 9 Average block coverage ( of test sets with fixed size . 19 10 Average effectiveness ( of test sets with fixed block coverage . 20 1 Introduction Random testing is a long standing testing technique and many researchers have studied its fault detection effectiveness [6, 7, 12, 17, 18]. The results of these studies are diverse. Some researchers [4, 6, 7, 13] conclude that random testing can be used to replace coverage based testing such as data flow and mutation testing. They make such conclusions based on the advantages of random testing such as reduced cost, high coverage in ....

....and loop termination conditions. In random testing, one generates test cases randomly in accordance with some input distri bution. In coverage based testing, one generates test cases to increase some form of coverage. The stopping criteria for random testing are based on statistical principles [6, 7, 12, 13]. For coverage based testing, the coverage criterion provides a stopping rule. A test set generated using random testing is likely to contain test cases that do not improve the coverage of interest. Depending on the stopping rule used, the size of a randomly generated test set might also be larger ....

H. Mills, M. Dyer, and R. C. Linger, "Cleanroom software engineering," IEEE Software, pages 19 25, September 1987.

.... all lines of the source code, forcing all the internal data to be initialized and used, applying all test scenarios, exploring all the inputs, and checking for functional completeness) Note also that software reliability engineering can greatly help the Cleanroom methodology developed at IBM [35] has been particularly useful in improving software quality and providing a quantitative measure for the quality of a software product at its release. The Cleanroom approach provides for the transition of process technology to the project staff and integrates several proven software engineering ....

Mills, H.D., Dyer, M., Linger, R.C., Cleanroom Software Engineering. IEEE Software 4, September 1987, pp. 19-24.

.... delivery [1] 12] concurrent software engineering, time boxing [2] spiral model [3] 2Handbook of Software Engineering and Knowledge Engineering iterative development, phased development, versioned implementation, short interval scheduling [4] or as we prefer to call itincremental development [5]. These models are usually called life cycle models. The confusion of terminology in this area is large. This is confusing for practitioners who want to compare and evaluate different approaches to decide how to implement it in their organization, as well as for researchers who want to understand ....

# Mills, H. D., Dyer M., and Linger, R. C., Cleanroom Software Engineering , IEEE Software, September 1987, pp. 19-24

....thus enabling automatic verication of the test results. Though a strategy of test case selection is beyond the scope of this paper, in the next paragraph we briey discuss the possibility of using the SUM for statistical usage testing. Statistical usage testing. In statistical usage testing [7], test cases are derived from a usage model. This model describes both functional and statistical properties of system usage. Experiences with the so called state hierarchy model [8, 9] shows that it is feasible to generate test cases automatically from a model of system usage. These test cases ....

Mills, H. D., Dyer, M. and Linger, R. C., Cleanroom Software Engineering, IEEE Software, pp. 19-24, September 1987.

....In effect, KobrA treats a component as 18 Colin Atkinson, Joachim Bayer, Dirk Muthig Fusion would treat a system. KobrA s incremental development strategy within framework engineering is also strongly influenced by Evolutionary Fusion [9] the incremental version of Fusion. The Cleanroom method [10] has also had a significant influence on KobrA s framework engineering approach. Although it is not an object oriented method, Cleanroom has pioneered many of the principle and techniques required to systematically engineer high quality software systems in the context of a tree based architecture. ....

Mills, H., Dyer, M., Linger, R.C., "Cleanroom Software Engineering", IEEE Software, vol. 4, 1987.

....attempt to nd a program input that will satisfy the testing requirement. The automation of test data generation is an important step in reducing the cost of software development and maintenance. A number of test data generation techniques have been automated. Random test data generators (e.g. [18, 20, 22]) select random inputs for the test data from some distribution. Structural or path oriented testdata generators typically use the program s control ow graph, select a particular path, and use a technique such as symbolic evaluation to generate test data for that path (e.g. 1, 3, 6, 15, 19] ....

H. D. Mills, M. D. Dyer, and R. C. Linger. Cleanroom software engineering. IEEE Software 4(5): 19-25, September 1987.

....and quality control in software engineering Quantitative measurements for quality control are not very common in software engineering practice, but there is some research into these applications. Statistical quality control is a crucial feature of the cleanroom approach to software engineering [MDL87] The PSP [Hum95] includes systematic collection of quality data and their use for process evaluation. But such techniques are not accepted throughout the industry. There seem to exist problems with their adoption. Basili and Weiss defined the Goal Question Metric (GQM) methodology for ....

H. D. Mills, M. Dyer, and R. C. Linger. Cleanroom software engineering. IEEE Software, pages 19--24, September 1987.

....This paper presents recent research related to both these areas. The basic idea behind the presented work is to combine and integrate two different approaches that focus on the modelling of usage: n Use Case Modelling, UCM, Jacobson et al. 1992) and n Statistical Usage Testing, SUT, (Mills et al. 1987). Both UCM and SUT address phenomena related to the modelling of anticipated system usage, although with different background and terminology. UCM focuses on requirements analysis and usage modelling as a tool for describing and understanding requirements, while SUT focuses on usage modelling to ....

....based on a user oriented approach. This requires a model of the anticipated usage of the software and quantification of the expected usage as the software is released. Several approaches have been investigated and used in this area. Musa (1993) for example, advocates operational profile testing, Mills et al. 1987) discuss random testing based on the operational profile and Runeson and Wohlin (1992; 1995) present an approach with user state dependent random testing based on the operational profile. The focus in this paper is on the latter approach, i.e. statistical usage testing based on a state hierarchy ....

Mills, H. D., Dyer, M., Linger, R. C., "Cleanroom Software Engineering", IEEE Software, pp. 19-24, September 1987.

....[18] is based on set theory and other basic elements of discrete mathematics, and incorporates novel structuring constructs (schemas and the schema calculus) Z technology also includes methods for the formal refinement of specifications into designs and code. The core of the Cleanroom method [10] [8] 16] is formal or semiformal specification, and corresponding verification done by a development group in review meetings. Other elements of the method include notations and techniques for stepwise refinement, testing based on expected usage patterns, statistical analysis of test results to ....

Harlan D. Mills, Michael Dyer and Richard C. Linger. "Cleanroom software engineering." IEEE Software 4, 5 (September 1987), pp. 19--24.

....require more than one person to be applicable. I continued to pursue the idea of using formal methods just to see if there was any method suitable for a one man, reengineering project. According to Hall [13] formal methods are superior to non formal methods to reduce debugging hours. Mills et al. [23] contradicts this however and states that even informal human verification can produce software sufficiently robust to go to system test without debugging . 3.1.1.1 Cleanroom engineering At first this method (further described in[8] 18] 23] 30] 31] was the most appealing to me. Cleanroom aims ....

....methods to reduce debugging hours. Mills et al. [23] contradicts this however and states that even informal human verification can produce software sufficiently robust to go to system test without debugging . 3.1.1. 1 Cleanroom engineering At first this method (further described in[8] 18][23][30] 31] was the most appealing to me. Cleanroom aims to minimise the number of errors in the code before compilation and hence it reduces test and debugging hours as most formal methods. A major problem though, is that cleanroom requires three teams (specification, development and testing) and ....

Harlan D. Mills, Michael Dyer, Richard C. Linger, "Cleanroom Software Engineering", IEEE Software, Sept. 1987, p.19-24.

....a tool that helps the tester create test data. Test data generators have been categorized into three groups: structural oriented test data generators [BKM91, BEL75, Cla76, DO91, How77, Kor90, RHC76] data specification generators [BF79, MM75, Mau90] and random test data generators [Stu85, VMM91, MDL87] This paper focuses on structural oriented generators, which are based on covering certain structural elements in the program. Usually, these generators attempt to generate test data to meet a testing criterion such as path coverage, branch coverage, mutation, etc. Structural oriented test data ....

H. D. Mills, M. D. Dyer, and R. C. Linger. Cleanroom software engineering. IEEE Software, September 1987.

.... into three groups: structural oriented test data generators attempt to cover certain structural elements in the program [5, 6, 7, 8, 9, 10, 11, 12] data specification generators generate test data from a formal description of the input domain [13, 14, 15] and random test data generators [16, 17, 18] create test data according to some distribution of the inputs without satisfying any test criterion. Because the analysis of the software is so complex, structural test data generators are intended to be used during unit testing. The ideas that have been presented in the past have not come into ....

H. D. Mills, M. D. Dyer, and R. C. Linger. Cleanroom software engineering. IEEE Software, September 1987. 27

.... the problem as with solving the problem [100] In large projects programming as problem solving may only be used in an early brain storming phase to find a suitable representation that later guides more traditional software engineering approaches, such as cleanroom software engineering [75]. A programming environment that facilitates problem solving should support change in representation. Simon points out that suitable representations are crucial for the solution of a problem [105] The process of problem solving includes changing representations until the solution becomes ....

Mills, H. D., "Cleanroom Software Engineering," Software Engineering, pp. 19-25, 1987.

....to run and to analyze. Good testing is a difficult task, requiring significant resource costs in developing and executing test cases and then analyzing the results. In general, complex systems cannot be certified as bug free. Even more rigorous approaches, like Cleanroom Software Engineering [58], serve to reduce defect rate rather than produce flawless code. Traditional testing organization includes three levels: unit testing, integration testing, and system testing. An additional level, acceptance testing, is outside consideration for our purposes; it is done to demonstrate to the ....

H.D. Mills, M. Dyer, and R.C. Linger. Cleanroom Software Engineering. IEEE Software, 4(5):19--25, September 1987.

.... and specialized) defined roles and responsibilities, well defined outputs, process metrics, and expected behaviors [Fagan 76, Fagan 86, Humphrey 97, Gilb 93, STR 96, Wheeler 96] A notable exception to these reviews are the mathematically formal verification reviews used in the cleanroom method [Mills 87] The purpose of walkthroughs, peer reviews, and inspections is to improve the quality of the artifact under review by removing defects. A fundamental premise of peer reviews is that others will find defects that the creator of the artifact overlooked. Review of the artifact by someone other than ....

....processes. These styles of review may be particularly effective for unanticipated events or as part of a risk mitigation strategy. 4.3. 2 Other Formalized Processes Formalism is an integral part of the cleanroom method and is a vital component of the verification procedures used in that method [Mills 87] Recently other review approaches, which are representative of the model based verification philosophy of relying on formalism to bring a systematic structure to the review process, have been proposed and investigated. For example, a comprehensive formal review technique has been defined that ....

Mills, H.; Dyer, M.; & Linger, R. "Cleanroom Software Engineering. " IEEE Software 4, 5 (1987):1987.

....come before and after the program s execution, respectively. Next, we prove that the software transforms one assertion (the precondition) into the other (the postcondition) Fagan (1986) reported that more than 60 of the errors in a software can be detected using informal software inspections. Mills et al. 1987) suggest that a more formal approach, using mathematical verification, can detect more than 90 of errors in a software. However, static testing techniques can only check the correspondence between a software and its specification (verification) but they cannot demonstrate that the software is ....

Mills, H.D., Dyer, M. and Linger, R. (1987). Cleanroom Software Engineering. IEEE Software, 4(5), 19--25.

No context found.

H. D. Mills, M. Dyer, and R. C. Linger. Cleanroom software engineering. IEEE Software, pages 19--24, September 1987.

No context found.

H. Mills, M. Dyer, and R. Linger. Cleanroom Software Engineering. IEEE Software, 4:19--24, 1987.

No context found.

Harlan D. Mills, Michael Dyer, and Richard Linger. Cleanroom software engineering. IEEE Software, 4(5):19--25, September 1987.

No context found.

Mills, H.D., Dyer, M., Linger, R.C., Cleanroom Software Engineering. IEEE Software 4, September 1987, pp. 19-24.

No context found.

H.D. Mills, M. Dyer, and R.C. Linger, "Cleanroom Software Engineering," IEEESoftware, pp. 19-25, September, 1987. Software Quality ConJbrence, October, 1994.

No context found.

Mills, H. D., Dyer, M., Linger, R. C.: `Cleanroom Software Engineering', IEEE Software, 1987, pp. 19-24

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