Talk:Cleanroom software engineering

Errata

Reference 1 seems to want to link to a paper by H. Mills, M. Dyer, and R. Linger entitled "Cleanroom Software Engineering" written in 1987. Instead it links to a paper written by M. Glinz and S. Fricker written in 2013 entitled "Our Shared Understanding in Software Engineering".

Merging?

See clean room design. Burschik 13:59, 7 December 2005 (UTC)

I'm not sure that merging the two articles would be appropriate. My understanding is that clean room design is a form of reverse-engineering. Cleanroom software engineering, on the other hand, is a software development methodology, and has nothing specifically to do with reverse engineering.

The name 'Cleanroom' in Cleanroom SE was taken from chip manufacturing cleanrooms, where (the idea was) high standards of quality are maintained with a rigorous process of defect detection. Cleanroom SE may or may not have been successful in achieving this, but what is certain is that clean room design and the Cleanroom SE method are completely different things. This article should no more be merged with clean room design than clean room design should be merged with the IC cleanroom article. 144.53.251.2 01:59, 19 April 2006 (UTC)

I have now substantially rewritten this article to more fully describe Mills' Cleanroom SE process. A merge no longer seems appropriate at all. --Allan McInnes (talk) 03:22, 28 April 2006 (UTC)

cleanroom software development in the legal sense

I recall the use of "cleanroom software development" to mean that one develops a piece of software based on known specifications (perhaps from an existing product), but making careful recordings and proofs that the developers never consulted nor used any proprietary information from other parties, particularly from the existing product whose specifications are followed.

The use of such cleanroom development is usually to duplicate the functions of a known product, without fringing upon somebody else rights.

For example, one could take a certain version of propriatary Unix and take a snapshot of all of its functions and assemble a team to re-develop the whole system.

In such a development process, the team must follow rigorous procedures approved by an IP attorney to ensure that the product so developed is completely legal.

I seem to recall that a version of BIOS was so developed during the early PC days. But I could be wrong.

Of course, such a process does not protect the developer from infringing upon patent rights. --Yuanliu 14:31, 1 May 2006 (UTC)

I think you're looking for clean room design (which applies to more than software engineering). There's a pointer to the other article at the top of this one, but perhaps it's not phrased clearly enough. I've tried to improve it. Do you have any suggestions for how to improve it further?--Allan McInnes (talk) 15:22, 1 May 2006 (UTC)

Wasn't it part of Cleanroom SE that developers were barred from running their code? I seem to remember that they only had a "half-compiler", one that checked syntax, but did not generate code; that only the quality assurance team would attempt to run code and do this under statistically controlled conditions. Maarten van Emden (talk) 00:31, 2 February 2009 (UTC)

More Methodologies

Currently, the article says that cleanroom combines formal methods, statistical quality control, and statistical testing. I think an expanded article might mention formal specications, proofs of correctness, Fagan inspections (at which specifications and proofs are examined), and iterative development (which allows quality measurements to feeback into the level of rigor of successive iterations). -- RLV 151.190.254.108 (talk) 14:20, 17 November 2009 (UTC)

And what were the results? Metrics ? without such data an useless article.