Reliability Attributes in Software Development

Reliability attributes are the measure of software reliability. There many be many reliability requirements for different software but all the software have some common reliability measures. Reliability attributes for different categories of software products may be different. Therefore, it is necessary to specify the that the level of reliability required for a software product in the software requirements specification document. There are some attributes that are required to significantly express the reliability of a software product. A good reliability measure should be dependent of observer so that different people can agree on the degree of reliability that a system has. For example, there are various techniques for measuring performance which possibly would result in obtaining the same performance value irrespective of who is carrying out the performance measurement. But practically it is very difficult to formulate a precise reliability measurement technique. The next base case is to have measures that relate with reliability. There are six reliability attributes which can be used to express the reliability of a software product. Rate of occurrence of failure (ROCOF) : ROCOF measures the frequency of occurrence of unexpected behavior of the software. It basically measures how many times the software product fails. ROCOF measure of a software product can be obtained by having the record of the behavior of a software product. ROCOF is basically the total number of failures occurring during the specified time interval. Mean Time To Failure (MTTF) : The average time between two successive failures is known as MTTF. It is obtained by observing a large number of failures in the software product. To measure MTTF, failure data for n failures is recorded. If the failures occur at the time instants T1, T2, …, Tn then MTTF can be calculated as:

MTTF = ( (T2 - T1) + (T3 - T2) + ... + (Tn+1 - Tn) ) / (n-1) 

It is notable that only run time is considered in the time measurements. The time for which the system is down to fix the error, the boot time and any other negligible time are neglected and are not included in the time measurements. Mean Time To Repair (MTTR) : When the software fails, it requires sometime to fix the error. MTTR is the measure of the average time system takes to find the errors that cause the failure and to fix them. Mean Time Between Failure (MTBR) : MTBR attribute can be obtained by combining the MTTF and MTTR attributes.

MTBF = MTTF + MTTR 

Thus, MTBF indicates that once a failure occurs, the next failure is expected after same time. In this case, time measurements are real time and not the execution time like MTTF. Probability of Failure on Demand (POFOD) : This attribute does not involve time measurements like the other attributes. POFOD measures the behavior of the system failing when a service request is made. For example, if POFOD measures 0.001 then it means that out of every 1000 one time the service requests would result in a failure. Availability : Availability of a system is a measure of possibility of availability of the system for use over a given period of time. It considers the number of failures occurring during a time interval. It also takes into measure the down time of a system when a failure occurs. This attribute is important for systems which are supposed to be never down. This plays a vital role in telecommunication systems and operating systems. These systems need to run even during the repair time.

Following points which strongly affects the software reliability.

• Complexity of Software: The high complexity of software is the major contributing factor of Software Reliability problems. This is tough scenario for developers as the rising complexity of software is difficult to optimize. Complexity is directly related to software reliability, so representing complexity is important. Complexity-oriented metrics is a method of determining the complexity of a program’s control structure, by simplify the code into a graphical representation. Representative metric is McCabe’s Complexity Metric.
• Optimistic Nature: Many people would think that once after the software can run correctly, it will be correct forever. This leads to feeling of security but actually we are going on path of self destruction if we believe like this. We needs to fix problems as soon as they arise.
  Affect of Environment :Once perfectly working software may also break if the running environmental changes. For example. let us talk the case of Ariane rocket. After the success of Ariane 4 rocket, the maiden flight of Ariane 5 ended up in flames while design defects in the control software were unveiled by faster horizontal drifting speed of the new rocket.
• Software failure: Software failures may be due to errors, ambiguities, oversights or misinterpretation of the specification that the software is supposed to satisfy, carelessness or incompetence in writing code, inadequate testing, incorrect or unexpected usage of the software or other unforeseen problems.
• Lack of effective Software Reliability Models: A proliferation of software reliability have emerged as people try to understand the characteristics of how and why software falls, and try to quantify software reliability. As many models as there are and many more emerging, none of the models can capture a satisfying amount of the complexity of software. constraints and assumptions have to be made for the quantifying process. Therefore, there is o single model that can be used in all situations. No model is complete or even presentative. One model may work well for a set of certain software, but may be completely off track for other kinds of problems

My Personal Notes arrow_drop_up

Save