Optimal Component Selection Approach for Fault-Tolerant Software System Under CRB Incorporating Build-or-Buy Decision

Abstract

Application Package Software (APS) has emerged as a ready-to-use solution for the software industry. The software system comprises of a number of components which can be either purchased from the vendor in the form of COTS (Commercial Off-the-Shelf) or can be built in-house. Such a decision is known as Build-or-Buy decision. Under the situations wherein the software has the responsibility of supervising life-critical systems, the inception of errors in software due to inadequate or incomplete testing, is not acceptable. Such life-critical systems enforces upon meeting the quality standards of the software as unforbiddenable. This can be achieved by incorporating a fault-tolerant design that enables a system to continue its intended operation rather than failing completely when some part of the system fails. Moreover, while designing a fault-tolerant system, it must be apprehended that 100% fault tolerance can never be achieved and the closer we try to get to 100%, the more costly the system will be. The proposed model shall incorporate consensus recovery block scheme of fault tolerant techniques. Through this paper, we shall focus on build-or-buy decision for an APS in order to facilitate optimal component selection thereby, maximizing the reliability and minimizing the overall cost and source lines of code of the entire system. Further, since the proposed problem has incompleteness and unreliability of input information such as execution time and cost, hence, the environment in the proposed model is taken as fuzzy.

Software component identification and selection: A research review

“…Generally, cost is defined as the overall cost of acquisition and adaptation of that component, but it can include maintenance costs, learning costs, modification costs, etc. Some approaches 11,66,67,[74][75][76][77][78] defined formulas for calculating the cost.…”

“…49 11,64-67,72-96 Nonfunctional requirements Include nonfunctional requirements 18 11,65,66,74,75,77-79,81,87,90-94,96,97 Provides a set of constraints deriving from how particular applications are built; this Software structure includes components and design patterns 10 11,65,67,79,81,83,93,95,97,98 used, communication and interface standards, and platform characteristics Abbreviation: NP, number of papers. Number of required interfaces 91,95 Number of components 11,64,72,73,76,84,86,88,92 Not mentioned 83 Delivery time 66,67,74,78,81,88 Testing time 81 Functionality 66,[77][78][79]85,90 Adaption time 97 Number of modules in the software 65,67,75,78,93 Training time 97 Number of provided interfaces 64,72,86,91,95 Deviational time 97 Number of alternative COTS available 65 Development time 66,81,83 11 Source lines of code 67,…”

“…Provided services 77,85,95 Reliability of the CRB scheme 74 Required services 77,85,95 Average number of failures 66 Cohesion 11,66 Probability of failures 67 Reusability 77,85 ______________________ Abbreviation: COTS, commercial off-the-shelf; CRB, collaborative rateless broadcast.…”

“…Evolutionary MOO based on GA 7 64,72,76,[84][85][86][87] Fuzzy mathematical programming (FMP) 3 67,74,78 Customized MOO (used LINGO optimization model solver) 2 81,82 Goal programming 2 75,96 Lexicographic MOO (LMO) 1 88 Fuzzy MOO 1 66…”

“…Second place belongs to reliability, and for the software to be reliable, it has to be made fault tolerant. Some publications, such as that by Jha et al, used approaches like the consensus recovery block to select components and make fault‐tolerant systems at the end. Fault tolerance means that in these systems, for some or all of the software modules, execution can be resumed even after failure with minimal loss of data and time.…”