Requirements, Design, Implementation, and Test Phases of Mathematical Model

Growth in Mathematics and engineering technology has led to production of Mathematics for highly complex situations occurring in industry, scientific research, defense and day to day life. The computer revolution is fueled by an ever more rapid technological advancement. Today, computer hardware and Mathematics permeates our modern society. Computers are embedded in wristwatches, telephones, home appliances, buildings, automobiles, and aircraft. Science and technology demand high-performance hardware and high-quality Mathematics for making improvements and breakthroughs. We can look at virtually any industry - automotive, avionics, oil, telecommunications, banking, semi-conductors, pharmaceuticals - all these industries are highly dependent on computers for their basic functioning. When the requirements for and dependencies on computers increase, the possibility of cries from computer failures also increase. It is always desirable to remove a substantial number of faults from the Mathematics. In fact the reliability of the Mathematics is directly proportional to the number of faults removed. Hence the problem of maximization of Mathematics reliability is identical to that of maximization of fault removal. At the same time testing resource are not unlimited, and they need to be judiciously used. In focusing on error prevention for reliability, we need to identify and measure the quality attributes applicable at different life cycle phases. As discussed previously, we need to specifically focus on requirements, design, implementation, and test phases. Mathematics development process is often called Mathematics Life Cycle, because it describes the life of a Mathematics product from its conception to its implementation. Every Mathematics development process model includes system requirements as input and a delivered product as output. Many life cycle models have been proposed, based on the tasks involved in developing and maintaining Mathematics, but they all consist of the following stages and faults can be introduced during any of these stages.

We determine a Mathematics release time T such that the expected total Mathematics cost is minimized subject to Mathematics reliability not less than a specified value, 0R. Theorem 4: For given 3C , uT , 1,iC and 2,iC for i=1,2,3

where 0T is the solution from Theorem 3 and 1T is the solution of 01)(RTxRStatement (1) notes that when the current amount of debugging does not

2

at what time should the debugging be stopped and the Mathematics released. Statement (l a) notes that if the current amount of debugging has met the reliability constraint then further debugging should be done until time 0T where 0T is defined above. Statement (l b) notes that if the current amount of debugging has not met the reliability constraint but the reliability constraint

then the program should be debugged until time 0T. Statement (1c) notes that if the current amount of debugging has not met the reliability constraint and the reliability constraint will be met at a time 1T, which is greater than 0T, then the program should be debugged until time 1T.Similarly, statement (2) notes that the current amount of debugging has already minimized the Mathematics system cost and that any further debugging will increase the total cost. This would imply that no further debugging should be done, but since there is a reliability constraint it must be checked to see if it has been met. Statement (2a) notes that the current amount of debugging has met the reliability constraint, and therefore, no further debugging should be done and the Mathematics should be released. Statement (2b) notes that the current amount of debugging does not meet the reliability constraint and that debugging should be

In the previous two sections optimal release times were determined for minimizing cost subject to no constraints and minimizing cost subject to a reliability constraint. Neither of these two sections considered the fact that there are three types of errors that determine the reliability of the system. In this section a method is presented that allows for constraining a particular type of error. Its importance is that while a program may be able to tolerate a number of minor errors it cannot tolerate critical errors. In this case a constraint can be put on the expected number of critical errors in the system before its release. It is also possible to set up constraints for each of the different types of errors independent of the other types. Consider both the expected total Mathematics system cost C(T) and the expected number of failure type i errors remaining in the system ()imT , as the evaluation criteria, then the optimal release problem can be formulated as

Since the data being used is of the form specified those equations were used to estimate the parameters. Specifically, the three equations represented by eqare solved numerically by 1b, 2b,

a. The results of these calculations are From these estimate and the parameters given, it is possible to determine uniquely the reliability equation and Table 1.

To find the optimal release time in this situation, it is necessary to use the relationships of The cost function is as follows:

To find the optimal release time in this situation, we use the relationships of Also a reliability constraint must be specified as

To find the optimal release time in this situation, we use the relationships of Also remaining error constraints must be specified. The remaining error constraints to be used are From these constraints we determined

4

within the framework of NHPP. The three error types are categorized by the difficulty of removal and detection. Minor errors (Type 3) are easily detected and removed; major errors (Type 2) are more difficult to detect and remove; critical errors (Type 1) are very difficult to detect and remove. We also presented an SRGM which incorporates the possibility of introducing new faults (i.e. secondary faults) into a Mathematics system due to the imperfect debugging of the original faults (i.e. primary faults) in the system. These new faults are assumed to occur in a delayed sense. Further we discussed the cost model with multiple failures, imperfect debugging as well as random life cycle in which cost also includes the penalty cost. The probability of perfect debugging can usually be increased with additional cost and, hence, it has a strong influence on total Mathematics development cost. A concept of testing level is introduced here. To achieve the lowest Mathematics cost, the management can use the proposed cost model to formulate the optimal testing level and release time problem by considering the effect of imperfect debugging. Our problem formulation and the proposed solution is useful in practice as the imperfect debugging probability can be managed by using test engineers with proper experience, by selecting testing strategy or even by including a suitable number of review staff.