Question: If identical copies of the same software are executing on multiple processors (i.e. redundant hardware) do we multiple the software failure rate by the number of processors?

Answer:  No.  Software failures are exclusively a function of inherent defects in requirements, design, and implementation.  These defects do not multiply by merely loading the software onto multiple hardware processors.  HOWEVER, when there are multiple processors running the software at the same time, the duty cycle for the software is multiplied by that number of processors.  So, you do need to reflect that in your system calculations.

If the software itself was redundant in addition to the hardware in that it was developed by different companies but performs the same function, then the failure rate for the software would be determined in exactly the same way that failure rate for redundant identical hardware systems is determined.  Even in this case, however, the failure rate is still not multiplied by the n number of processors.

 Question:  Our software is being developed by 2 different companies.  How do we model that?

Answer: You should create 2 components for each company within the Prediction general inputs page.  The reason is that each company is almost certain to have different practices for developing software even if each company has the same SEI CMM level and is bound by the same project requirements.

Question: It seems as though size is the major variable in determining MTTF, failure rate and the other outputs.  So, why worry about the other inputs?

Answer:  Size is an important variable because it is a direct multiplier in the MTTF and failure rate formulas.  However, it is not the only important variable and certainly not the only variable that is sensitive to changes.

Defect density is also a direct multiplier.  The difference between the best and worst defect density prediction possible within Frestimate is more then 100 excluding the possibility that you may input your own historical data. 

Q can have a huge impact on MTTF and failure rate.  Q does not impact defect density but it does impact how quickly defects become failures in the field which is an input for MTTF and failure rate.  The bigger Q is, the faster the software grows.  The smallest Q value (1) means that the MTTF after some growth period will be essentially unchanged while a Q of 20 would mean a very very large change.  The sensitivity of Q varies not just with it's own size, but the size of the growth period. 

Growth period can have a huge impact on MTTF and failure rate.  The bigger this value is and the more impact the Q value will have on the MTTF and failure rate results.

Question:  Should we include the operating system (OS) in our prediction?

Answer:  Yes you should.  The problem you may encounter is that defect densities or MTTF or failure rate values for operating systems can be difficult to come by.  You should treat the OS as a component in the Frestimate file and attempt to collect as much information on it as possible.  You may find that the MTTF is published for this component.  In that case, simply enter it directly into the component page. 

Question:  How come there are so many software reliability models?

Answer:  Actually, there are fewer software reliability prediction models then there are hardware reliability prediction models.

All software reliability prediction techniques are from the same model form which is:

Failure rate =

(Defect density * Size) 

-----------------------------

(Duty cycle * (Statistical method to extrapolate defects to failures)

 

Usually the statistical method is (1-exp(-Q)) however, it can be any other distribution such as the Weibull.

 

The only difference in the available techniques is the parameters that are used to predict defect density.  All of the defect density prediction methods use historical data.  All of them correlate one or more development practices to defect density.  The only difference among these techniques is how many development practices are modeled.

 As far as software reliability estimation models go, at one time there were several dozen of these available in literature.  However, even these models all have the same generic model type which is that they use the number of faults detected during some interval of time to extrapolate failure rate or MTTF.  Within this generic model type the statistical methods used to extrapolate failure rate are:

	Weibull - derivatives of the Weibull include Exponential and Raleigh.
	Derivatives of the exponential model include the Logarithmic model and exponential Bayesian models and exponential geometric models.
	S shaped models
	A variety of other models that are derivatives of the above

Most of these dozens of models are derivatives of one of the above basic model types and there are a variety of Goodness of Fit approaches to determine which statistical method is the most accurate.