|
Cleanroom SOftware Engineering
is this process still in use or has it been consigned to the dustbins?
once upon a time, it was fairly hot especially from IBM which have done a few projects using it.
a few books have been written on it, however no new articles or new books on it recently.
any one know more?
eddy
Wednesday, January 21, 2004
"In a Cleanroom development, correctness verification replaces unit testing and debugging. After coding is complete, the software immediately enters system test with no debugging. All test errors are accounted for from the first execution of the program with no private testing allowed"
No debugging and no private testing sounds like every developer I know...
Wednesday, January 21, 2004
Sounds very silly to me. Not allowing any developer testing is a recipe for disaster. Is it a wind-up?
Isn't it generally accepted that the sooner a bug is picked up the cheaper it is to fix ? Leaving everything to the System Test stage seems crazy. Apart from anything else, it may not even be possible to run the application, if there is something wrong with the startup code, or there is an integration problem.
Steve Jones (UK)
Wednesday, January 21, 2004
golly, 'cleanroom' for me brings up images of developing a compatible product without reverse engineering nor borrowing from that existing product; e.g. compaq and the ibm pc bios.
Obviously off the cuff interpretations can be completely wrong? Oh well.
i like i
Wednesday, January 21, 2004
I /think/ the point is that developers should have made sure their code is right in the first place. At least I hope so...
Wednesday, January 21, 2004
Yes, that's the point. I think the idea is to create an environment in which developers are strongly motivated to make their code work first time. And of course also to stipulate practices that help them attain that goal.
It's always seemed pretty implausible to me: doubtless you can get your defect counts down this way, but at the cost of making the software much slower to develop and making each defect costlier to fix. It might be a good tradeoff when it's essential to make the defect rate really, really low (controlling an aeroplane or a heart pacemaker, say), but in general it must surely be inefficient in terms of cost to reach a given defect level. But I've never actually done it, so what do I know?
Gareth McCaughan
Wednesday, January 21, 2004
Cleanroom development was (maybe still is), more about reproducing the behaviour of one system without the developers inspecting the internals of that system or even knowing how the system was meant to work.
The experience I had of this was in BIOS development by clone manufacturers in the 80's (Phoenix and such as well as computer manufacturers).
Basically you have someone tear down the system to be emulated, write up the detailed specification of how the system behaves and deliver that to the cleanroom. The engineers in the cleanroom develop only according to that specification and test only on their own system, they make no tests or comparisons on the original system.
Engineers outside the cleanroom do make comparative tests and make change requests based on the desired behaviour.
So actually it wasn't so much IBM doing this as everyone else doing it to match the IBM BIOS.
And no, I wasn't a cleanroom engineer, but I was someone that ran a support department for a clone manufacturer (Tandon) and produced patches from time to time to the BIOS ahead of fixes being implemented at the factory.
Simon Lucy
Wednesday, January 21, 2004
Sorry Simon, but Google seems to disagree - http://www.google.co.uk/search?q=Cleanroom+SOftware+Engineering&ie=UTF-8&oe=UTF-8&hl=en&meta= (see first entry).
Wednesday, January 21, 2004
so simon, I wasn't going mad imagining that I had heard 'cleanroom' mean something about avoiding copywrite infringement. Clearly there are two different 'cleanroom' meanings within software development.
i like i
Wednesday, January 21, 2004
IMHO, the proponents of the Cleanroom Software method made a bad choice of names. Simon's definiton seems to me to be the much more longstanding and common one. I've been in this field for 24 years...
My $0.02
sgf
Wednesday, January 21, 2004
Wasn't this also known as IBM's "Gold Code" process? I recall reading about this 10 or so years ago. It was basically a process where the developer would carefully work out the design of a given function (perhaps on paper), thoroughly considering all aspects of the problem, and only after that would the coding start, carefully and slowly.
In some side-by-side tests, the "Gold Code" teams supposedly produced much better code than the traditional methods of the time, and in less overall time.
I think the goal of the process was to get to "ship quality" code faster with just one beta release, rather than five or six alpha and beta releases.
Mark Newman
Wednesday, January 21, 2004
...counts on fingers...
hey, I've been in this trade 24 years too, well maybe 25. But that wasn't me justifying myself.
Simon Lucy
Wednesday, January 21, 2004
actually there is a recent article in DDJ about cleanroom software engineering in the August Issue 2003
Cleanroom Software Engineering
Shawn P. Garbett
By focusing on defect prevention rather than defect removal, cleanroom software engineering helps you develop high-quality software with certified reliability.
hmm maybe not so dead after all this particular software engineering process.
any more comments/views/insights? keep them coming
eddy
Wednesday, January 21, 2004
I don't think Cleanroom is a very realistic process these days. Back in the day, they were coding close to the machine. These days, even if your code LOOKS correct, you must still rely on many third-party libraries, JVMs, and Windows OS to be bug-free. good luck! :-)
runtime
Wednesday, January 21, 2004
"Cleanroom Software Engineering" takes it's name from the semiconductor industry. Used to be, yields were really low, and companies spent a lot of money to detect bad chips. Turns out the problem was dust and imperfections. By creating the "clean-room" environment, it prevents the defects from showing up in the first place.
When doing clean-room software engineering, you are specifically restricted to using only constructs that are easily verifiable (i.e. via code inspection) to be correct. That's why you don't do a lot of up front testing. You don't test that you code runs correctly under these circumstances; you PROVE that your code is correct.
It seems to be a time consuming and soul sucking process to me, but it does get results. Wether it's worth the costs is another question.
-Chris, vaguely remembering a software engineering class from 7 years ago
Chris Tavares
Wednesday, January 21, 2004
"...counts on fingers...
hey, I've been in this trade 24 years too, well maybe 25."
Set the bazookoids to heat-seeker. I just spotted the genetic mutant.
Jenny who?
Cat
Thursday, January 22, 2004
You've not heard of Chisenbop then?
http://klingon.cs.iupui.edu/~aharris/chis/chis.html
Simon Lucy
Thursday, January 22, 2004
I can't do that stuff, I don't have fingers. Besides, it would make me look bad. Owwwwww.
Cat
Thursday, January 22, 2004
 Recent Topics
Fog Creek Home
| 
