SMERFS (Statistical Modeling and Estimation of Software Reliability Functions) is a program for estimating and predicting the reliability of software during the testing phase. It uses failure count information to make these predictions. To run SMERFS from this control panel, the user supplies five pieces of information. These are the name of the history file, the name of the assumptions file, the name of the input data file, the name of the output data file, and the type of data contained in the input data file. The history file is an output file that will be created by SMERFS. It is a trace file that contains all of the user input and SMERFS outputs for a particular run so that the user can go back and look at the run at a later time. USERS WILL USUALLY WANT TO PRODUCE A HISTORY FILE, SINCE INFORMATION SUCH AS MEAN-TIME-TO-FAILURE PLOTS ARE SAVED IN THIS FILE. The assumptions file is an input to SMERFS which is used when the user queries SMERFS about the characteristics of a particular software reliability model. SMERFS uses the contents of this assumptions file to reply to the user's query. The input data file contains the failure history data on which SMERFS will actually operate to produce the reliability estimates and predictions. The user must also specify the type of data contained in the input data file by clicking the appropriate radio button. If the selected data type does not correspond to the type of data actually in the input file, the estimates and predictions made by SMERFS will not be valid. The output data file is a file that the user can specify to which SMERFS will write failure history data created or edited by the user during the current SMERFS session. This is different from the history file described above, since the history file is a trace file which re- cords all user input and SMERFS responses. The output data file is actually a failure history file, created by the user, which can be used in subsequent sessions as an input data file. The user can specify these files in the text entry areas. If they are specified as file names without a path name in front of them, SMERFS will assume that these files are in the current directory. These files may also be specified as FULLY QUALIFIED file names if the user wants to make use of files that are in directories other than the current one. The character length limit for file names is 128 characters in this im- plementation. Note the following: 1. The user can elect to not produce a history file by clicking the "none" button associated with the history file name text box. 2. The user can elect to input failure history data from the keyboard rather than reading it in from an input data file. This is done by clicking the "keybd" button associated with the input data file name text box. If keyboard input is selected, the user must still specify the type of failure data to be input by clicking one of the four "data type" radio buttons described above. IN THIS IMPLEMENTATION OF THE SMERFS CONTROL PANEL, KEY- BOARD INPUT AND DATA FILE INPUT ARE MUTUALLY EXCLUSIVE OPTIONS. 3. The user can choose to specify no output data file by clicking the "none" button associated with the output data file name text box. IT SHOULD BE NOTED THAT IT IS POSSIBLE TO SPECIFY KEYBOARD INPUT AND NO OUTPUT FILE. THIS IS GENERALLY UNWISE, HOWEVER, SINCE ANY DATA CREATED BY THE USER IN THIS SITUATION WILL NOT BE SAVED FOR FUTURE USE. If users want to change directories, they click the "Change Directory" button. A dialog box containing a text entry area, an "OK" button, and a "CANCEL" button will appear. The user will then enter the name of the directory to change to in the text entry area. Pressing the "OK" button will cause a directory change to that directory, while pressing "CANCEL" will cancel the operation and leave the user in the directory in which he started. If the user enters the name of a non-existent directory or the name of a directory which he cannot access, error message boxes with the appropriate error messages will appear. When a successful directory change has been made, the new directory name will appear in the "Current Directory" text window in the main control panel. Directory names are limited to 128 characters. In this implementation, users need to run SMERFS from a directory in which they have write permission. This is because SMERFS creates tempor- ary history files in the current directory, even if the user has requested that no history files be produced. The temporary history files are removed at the end of the current SMERFS session. However, SMERFS must be able to create these temporary files during the session. The following table gives a list of assumption files, data sets, and sample SMERFS sessions that are available for the user to inspect or use or use while running SMERFS. DATA SET NAME interval1.dat interval2.dat cpudata1.dat ========================================================= Assumptions File: smerfs3.assum smerfs3.assum smerfs3.assum Sample Scenario: interval1.his interval2.his cpudata1.his The assumptions file is used to actually run the model. The sample scenario is a file that the user can view to see what SMERFS actually looks like when it's running. Interval1.dat and interval2.dat are "test interval length/failure count" type of data,, while "cpudata1.dat" is of the type "Execution time between failures." All of these files are available in the ~cs577/CASE/reliability directory. For more information on SMERFS, consult the SMERFS user's guide. This is a technical report available from the Naval Surface Weapons Center, NSWC TR 84-373, "Statistical Modeling and Estimation of Reliability Functions for Software (SMERFS) User's Guide." (Revision 3 published in 1993.) For more information on software reliability modeling in general, refer to Chapter 4 "Software Reliability Modeling Survey" of this Handbook (Handbook of Software Reliability Engineering), as well as "Software Reliability: Measurement, Prediction, Application" by John Musa, Anthony Iannino, and Kazu Okumoto, also published by McGraw-Hill in 1987. In addition, The IEEE has a committee devoted to Software Reliability Engineering which sponsor annual International Symposium on Software Reliability Engineering (ISSRE).