Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!rex!ames!dftsrv!bethe.gsfc.nasa.gov!xrtnt From: xrtnt@bethe.gsfc.nasa.gov (Nigel Tzeng) Newsgroups: comp.software-eng Subject: Clean Room - NASA SEL Message-ID: <2288@dftsrv.gsfc.nasa.gov> Date: 7 Jun 90 22:55:27 GMT Sender: news@dftsrv.gsfc.nasa.gov Reply-To: xrtnt@bethe.gsfc.nasa.gov Organization: NASA Goddard Space Flight Center - Greenbelt, MD, USA Lines: 88 News-Software: VAX/VMS VNEWS 1.3-4 There was a presentation of the Cleanroom approach at the Fourth Annual SW Engineering Workshop at Goddard last november. I don't have my notes with me but I do have the proceedings here. They actually developed 33,000 lines of FORTRAN code for the Flight Dynamics Division (FDD) using Cleanroom Methodology. The project was split into 6 builds of roughly 5000 lines per build. The work was spread over a 22 month period. At the time of the presentation the system had not undergone final integration and acceptance testing. Here are some of the numbers presented. The comparisons are against typical NASA Software Engineering Lab (SEL) projects. SEL projects tend toward smaller programs to test SE practices so it is expected that these "typical" values reflect projects that used "leading-edge" methodologies. Typical SEL SEL Cleanroom Errors/KSLOC 6.0 2.7 Changes/KSLOC 21 14 LOC/Staff Hour 2.9 4.9 Percentage of Errors < 1 hr to fix 58% 90% There's more but you can get copies of the Proceedings by writing to System Development Branch Code 552 Goddard Space Flight Center Greenbelt, MD 20771 The study was perfomed by Ara Kouchakdjian (Univ of MD), Scott Green (NASA/GSFC), and Victor Basili (Univ. of MD) and the NASA SEL (Code 552). The presentation was given by A. Kouchakdjian in session 1 of the conference. - My personal feelings about this study was that it sounded like an interesting approach but somewhat impractical for the NASA environment - at least at Goddard. The Code 500 projects (SEL) are well funded (ie fully staffed) and in general without intense time pressure. They also probably get a reasonably nice work environment. Which is pretty important if half your staff is engaged in code reading most of the time. It seems that the rest of Goddard suffers from housing shortage. Programmers are crammed into cubicles or offices 2-5 at a time and machines can be overloaded. The COBE (Cosmic Background Explorer) Project suffered from this for a long while. Actually we still do. Last week we had jackhammers banging away next door with dust everywhere (they are converting a roof into office space...). I'd like to see code reading done in that environment. I am not thrilled about the idea of not actually being able to do get at my own code and seeing the stuff work (or not work). I'm not convinced that you wouldn't see the same sort of performance improvement with increased code readings and spending more time on the code/design verification phase. The artificial seperation of the devloper from the computer strikes me as just another gimmick. It seems that the methodology would also remove much of the pleasure of programming. I think it would for me. There is something satisfying to see your code do something new at the end of the day. A general reinforcement that you actually accomplished something worthwhile. Otherwise you'd have to wait for a major build or even launch to see the "fruits" of your labor. I do find a lot of satisfaction from finding an efficient algorithm or a better approach to a problem but it seems that this "reinforcement" is also removed from the developer in their model. It appears that the analysts get to deal with the "interesting" problems. Face it...a lot of the problems that we as developers solve aren't very difficult. Just time consuming and tedious. Give the tough (read as "enjoyably challanging") decisions and design work to analysts and the pleasure of seeing your code actually do something useful to the testers what do you have left? A test report? No Thanks. I do like the idea of a seperate test team. Parallel testing and coding with seperate teams seems to produce be more efficient. This isn't unique to the cleanroom approach but it is more clearly defined in this methodology. Having constant feedback on the code would increase the chances that the requirements are met. It will hopefully also find problems earlier and produce a more robust product. I've rambled on enough... NT -------------------------------------------------------------------------------- // | Nigel Tzeng - STX Inc - NASA/GSFC COBE Project \X/ | xrtnt@amarna.gsfc.nasa.gov | Amiga | Standard Disclaimer Applies: The opinions expressed are my own.