joshua@athertn.Atherton.COM (Flame Bait) (11/30/89)
I have a simple question, I'm looking for a simple answer :-)
Given any information you want, predict when a software project will have
fewer than N bugs, and make the prediction after "new" coding has stopped,
but while debugging and testing is still going on.
The situation in detail:
I'm about to start a small (1 person, a few months) project; I know that
at some point in the future, I'm going to have the whole thing written,
and I'll be testing it (with help from QA) and fixing bugs as fast as I
can, but I will not be adding functionality. During this process (which
I expect will take at least half of the coding time) my boss will want
to know when it will be ready. I will (of course) have no idea. I might
be working on the last bug, or the 100th to last bug. The ship criteria
will be something like "no class 0 bugs, max of one class 1 bug, and three
class 2 bugs". Since the project hasn't started yet, I can set up to
keep track of any statistics you might want.
What I'm looking for (besides the holy grail) is a program which looks at
the bugs per hour testing, or something similar, and predicts when the bugs
will drop below our ship criteria. Obviously, I can eyeball the curve and
make a guess, but I'd like something with some empirical evidence behind
it.
Lastly, I'm mathmatically illiterate, so I'd like the answer in the form
of a computer program, not any complicated math. I do own NUMERICAL
RECIPES (Press et al.), so an answer can reference that.
Please post your answers. I want to see other peoples comments on the
presented solutions.
Joshua Levy
-------- Quote: "Hofstaedter's Law: It always takes longer than
Addresses: you expect, even if you take into account
joshua@atherton.com Hofstaedter's Law"
{decwrl|sun|hpda}!athertn!joshua work:(408)734-9822 home:(415)968-3718crm@romeo.cs.duke.edu (Charlie Martin) (12/01/89)
I don't have the exact reference right at hand, but the IBM Software Clean Room work on statistical testing might offer an attack. You would basically develop an empirical for the number of remaining bugs given the time to find a bug, then use that. On the other hand, for a massive project you can deal with this, both in terms of the workload testing jig and the statistical munging of the data; on a one-person project, it may not be a valid model or worth the trouble. Have you considered playing Michaelangelo and saying "whem I'm done!" Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
marks@agcsun.UUCP (Mark Shepherd) (12/01/89)
In article <15030@joshua.athertn.Atherton.COM>, joshua@athertn.Atherton.COM (Flame Bait) writes: > I have a simple question, I'm looking for a simple answer :-) > > Given any information you want, predict when a software project will have > fewer than N bugs, and make the prediction after "new" coding has stopped, > but while debugging and testing is still going on. > I don't believe that there is a reliable, quantitative way of producing the answer you're looking for. I do believe that the answer depends (at least in part) on the following: How well do you understand the requirements? How good is the design? How good is the designer? How good are the tools? How much time was spent in requirements analysis and design? Have you ever done this sort of thing before? Are there mutually dependant subsystems (eg hardware and software) that must be simultaneously debugged? Was the project done by a small coherent team? Was the team all in one location? Does your management place higher priority on schedule, or on quality? Did you prototype the system, or at least the tricky or poorly understood parts? Are you willing to redesign/rewrite the pieces that turn out to be poorly designed or implemented? Is there a comprehensive test plan? I'm afraid that these questions are much more difficult to answer than the usual QA ones (how much paper was produced? was MIL-STD abc123 followed?). Sorry. Mark Shepherd Ampex Corporation ...!ucbvax!avsd!dse!agcsun!marks These are my opinions.
mjl%ritcv@cs.rit.edu (12/02/89)
In article <15030@joshua.athertn.Atherton.COM>, joshua@athertn.Atherton.COM (Flame Bait) writes: > I have a simple question, I'm looking for a simple answer :-) > > Given any information you want, predict when a software project will have > fewer than N bugs, and make the prediction after "new" coding has stopped, > but while debugging and testing is still going on. Sounds like you should be looking at "Software Reliability: Measurement, Prediction, and Application" by John Musa, et. al. (McGraw-Hill, 1987). They address these problems and several others from a statistical profile viewpoint. The underlying math is heavy duty indeed, but it can be skipped initially, as they provide some basic parameters you can fit to your own project. I heartily recommend it. Mike Lutz Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!rit!mjl INTERNET: mjlics@ultb.isc.rit.edu