# Introduction here is probably no other human made material which is more Omni present than software in our modern technical worlds. New applications softwares are coming into the market day by day to meet the human requirements. Software has become one of the key parts of many aspects of society like banking, telecommunications, automobiles, aviation, shopping, auditing, web teaching, personal entertainment, and so on. Today, science and technology demand high quality software for making improvements and breakthroughs [1]. SRE is mainly focused on key properties like reliability that can be defined as probability of a failure free operation over a period of time under specified environment [2]. Among many other properties like functionality, flexibility, capability and so on reliability has got its own importance and accepted as the major factor in quality assessment of software. This assessment quantifies failures that make the powerful systems to inoperative. SRE is defined as the qualitative study of the operational behavior of software based systems with respect to user requirements concerning reliability. As a proven technique, SRE has become a standard and currently practiced by more than 50 organizations in their software projects and reports including AT&T, Lucent, IBM, NASA, Microsoft, and many others in Europe, Asia, and North America. However, this number is still relatively small compared to the large amount of software producers in the world. Author ? : Assistant Professor, Department of Computer Science and Engineering, Muffakham Jah College of Engineering and Technology, Hyderabad, Andhra Pradesh, India. E-mail : kvsreddy2012@gmail.com Author ? : Professor and Head, Department of Computer science and Engineering, VNR Vignana Jyothi Institute of Engineering and Technology, Hyderabad, Andhra Pradesh, India. E-mail : rbhogapathi@yahoo.com Reliability measurements are useful in supporting management of the software development process. For instance, obtaining reliability estimates early in the development process can help determine if the software system is on track to meet its reliability goals and therefore increase management effectiveness. Because research in software reliability is both necessary and beneficial, this paper proposes further work in this field of software engineering. In particular, efforts are focused towards structure based software reliability models. This paper is organized as; section II discuss about the history of SR and the structural model, Section III explains about the proposed component model for SR estimations ending with section IV and V about the results and discussions. # II. Background a) Software Structure Model Software structure model can be defined by the components from which the software system is built and by establishing the relationships between these components. Many methods are available for the designing of software systems, and these methods provide a framework for decomposing the problem of software design into smaller pieces that are related to one another. Because the design process ultimately provides a blueprint for implementation, software design methods can be used to describe how software is physically decomposed. The two most popular categories of software design methods are Structured Design (SD) and Object-Oriented Design (OOD). Previous work on structural reliability models assumes that software is designed according to SD principles [3, 4, and 5]. The proposed model assumes that software is designed according to OOD principles. Relationships are the basis of methods for calculating a total software system reliability figure from the reliability of the components. Current structural models follow one of two trends: execution path based [6,7]. The practicality of the execution path approach is questionable; execution paths are preferred to the transition probability models because of the Markov process which does not reflect reality. In this paper, execution paths are used; however, execution paths are considered as series of component executions and reliability of a path will be obtained from the reliability of the path components. Although the problems associated with execution paths can now potentially arise, the mathematical formulas derived for the software system reliability estimation will be simplified in a way that prior knowledge of the set of all execution paths is not necessary. Also, it is important to note that the combination of relationships and components that form the software structure model is extremely simplified. As software systems scale up, it might be necessary, for practicality purposes, to provide other components to group sub-components and other relationships. # b) Component Model As stated in [7] shooman's model provides an equation to estimate the expected number of software failures (n f ) (1) n is the number of software tests, 1 is the execution path usage ratio and q is the probability of failure of the path and n is the number of execution paths. Using the above equation (1) the software system probability of failure Q s can be defined as (2) The above equation describes the system unreliability is equal to the sum of the likelihood of failure over every execution path weighted by its corresponding execution path usage ratio. The software reliability R s is defined as (3) III. # Methodology The probability of a successful path represents that all components in the path execute successfully. In terms of conventional reliability theory, execution paths are equivalent to series reliability models. Series models require that all components work properly for system success. For independent component failures, the probability of failure along a given execution path is solely a function of the probability of failure of each component along the path. # (4) Where n i is the number of components on the respective path (5) Unreliability can be written as (6) If the components have a high reliability then the above equations can re written as (7) (8) Therefore software reliability can be defined as (9) Where D k represents the probability of failure of component. The component usage ratio parameter represents the ratio of total component execution time over the total software system execution time. The value of the component usage ratio is . The total of all components usage ratios is equal to 1. The component usage ratio weights the component reliability impact of the component reliabilities on the overall software system reliability. As a general the calculation of software reliability based rule, the reliability of a component frequently on component testing and/or inspection does not executed is expected to have more impact on the produce an accurate estimate of the reliability of overall system reliability than a component rarely the software system. When components are executed ? . . In this experiment we have considered a data as shown in the table 1. The above figure shows the impact of components with respect to the failures and the reliability. It is clear that the components reliability plays a prominent role in deciding the quality of the software. Numbers of failures are very low at a higher component and decreases gradually when it comes for the reliability. ? ? 1 ! 1 ? 1 ! 1 ? ! ? ! 1 1 ? " # $ # % # " # ( ) * + K C k D k ? k 1 0 # Results and Discussions V. # Conclusions A new mathematical model of software reliability is proposed in this paper. This focuses mainly on the impact of components when the reliability of software is estimated. It is proved that the malfunctioning of components have a great impact on the estimated reliability of software and the number failures are not optimal for calculations. 10![Calculation of component execution time is more difficult because it is necessary to track when each component is executed. The total component execution time describes the time spent executing instructions inside a component.](image-2.png "( 10 )") 12![Figure 1 : Performance analysis of component Impact](image-3.png "Figure 1 :Figure 2 :") 1 * software Reliability Engineering: A road map RMichael Lyu IEEE conf on .future of software engineering (FOSE-2007 * Standard Glossary of Software, Engineering Terminology, STD-729-1991 Ansi/Ieee 1991 ANSI/IEEE * Assessing Reliability of Modular Software PKubat Operations Research Letters 8 1 February 1989 * Software Reliability Model for Modular Program Structure BLittlewood IEEE Transactions on Reliability 28 3 August 1979 * A Statistical Approach for Determining Release Time of Software System with Modular Structure YMasuda NMiyawaki USumita SYokoyama IEEE Transactions on Reliability 38 3 August 1989 * Software Engineering: Design, Reliability and Management MLShooman 1983 McGraw Hill * A Micro Software Reliability Model for Prediction and Test Apportionment MLShooman Proceedings 1991 International Symposium on Software Engineering 1991 International Symposium on Software EngineeringAustin, Texas May 1991 * The Trace Assertion of Module Interface Specification DLParnas YWang 89-261 October 1989 Queen's University Technical Report * A User-Oriented Software Reliability Model RCCheung IEEE Transactions on Software Engineering 2 March 1980 * Object-Oriented Analysis and Design with Applications GBooch 1994 The Benjamin/Cummings Publishing Company Inc