mrb@sei.cmu.edu (Mario Barbacci) (06/02/89)
[I am posting this on behalf of the requesters. Contact them directly if you have information relevant to their project. MRB] Project Failure and Fault Data for Important Software Reliability Research Some important current software reliability research is directed toward trying to predict software reliability for systems not yet built. Several challenging problems must be solved to do this, but results are promising. You can contribute to this effort and gain the satisfaction of participating in a potentially important advance in the field by collecting data to help solve one of the key problems. We need the following information on each of many projects: 1) Failure intensity with respect to execution time that would be experienced in operation if the program were released at the start of system test. If execution time can't be measured, we can use a quantity that is proportional to it, provided the constant of proportionality is known. A. This would be best obtained from load testing without correcting faults and with runs made at frequencies corresponding to the operational profile. We can accept either measured failure intensity (failures/CPU hr.) or raw failure data (time intervals between failures or failures per time interval.) In the latter case we will compute the failure intensity. B. A second choice is failure data obtained from testing without repeating runs and with faults being corrected. Here, we will have to adjust the data to obtain the operational failure intensity. We can accept raw failure data in two formats, time intervals between failures or failures per time interval. 2. Average instruction execution rate in object instructions/sec. 3. Program size in object instructions. 4. The number of faults remaining in the software at the start of system test. We will approximate this quantity from faults uncovered during system test, or preferably, faults uncovered during system test plus some period of operational use. If faults are introduced due to code that is added or modified after the start of system test, these faults should not be counted. If they can't be identified, we need to know the number of source lines added/modified after the start of system test and the total number of source lines at the start of system test, so we can compensate for them. 5. Information about the structure of the program (optional). A. Average (taken over all possible runs) number of executions/instruction for a run and average (taken over execution time) number of parallel paths through a program. B. A second choice is access to the source code. We need a contact who knows the project and the data taken and can interpret the data to us, answer questions, etc. Similarly, we will be in contact with participating projects to clarify the foregoing requirements and help interpret them in the light of data that is available. We assure complete confidentiality to participating projects and will provide participants with analysis and interpretation of their data. If you are interested in participating in this research effort, please contact: Dr. Anneliese von Mayrhauser or James Keables Department of Computer Science AT & T Bell Laboratories Illinois Institute of Technology 1100 E. Warrenville Road Chicago, IL 60616 Naperville, IL 60566 312/567-5156 312/979-1045 -- ------------------------------------------------------------------------ Mario R. Barbacci, arpanet: mrb@sei.cmu.edu uunet: ...!harvard!sei.cmu.edu!mrb Software Engineering Institute, CMU, Pittsburgh PA 15213, (412) 268-7704