xrtnt@bethe.gsfc.nasa.gov (Nigel Tzeng) (06/08/90)
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.