Method for assessing software reliability of the document management system using the RFID technology

The deliberations presented in this study refer to the method for assessing software reliability of the document management system, using the RFID technology. A method for determining the reliability structure of the discussed software, understood as the index vector for assessing reliability of its components, was proposed. The model of the analyzed software is the control transfer graph, in which the probability of activating individual components during the system's operation results from the so-called operational profile, which characterizes the actual working environment. The reliability structure is established as a result of the solution of a specific mathematical software task. The knowledge of the reliability structure of the software makes it possible to properly plan the time and financial expenses necessary to build the software, which would meet the reliability requirements. The application of the presented method is illustrated by the number example, corresponding to the software reality of the RFID document management system.


Introduction
The software reliability is one of the most important indicators of the software quality.One of the methods for modeling software reliability is to treat the software as monolithic entirety, while considering its interactions with the external environment, without trying to model the internal structure of the software.Such approach is inappropriate for modeling larger IT systems, with complex internal architecture.There is a demand for the modeling techniques of the software reliability, using the knowledge of its internal structure, e.g.module structure.The basic unit for determining the software structure is its component -often a module -understood as a logically independent software element, which performs well a specific function.It means that the modules may be designed, implemented and examined independently.
The behavior of the software, depending on the manner, in which different software modules affect each other, is defined by the software architecture.The interactions between different modules in the form of mutual control transfer are present only during the execution of the computer program.The software architecture may also contain some information on frequency of activation of the individual modules.When the software is working, some emergency situations related to software errors may occur.The software error may be connected with the implementation of any module or transfer of control between the two modules.A possibility of occurrence of some emergency situations during the use of the software is described by various software reliability indicators.The knowledge of the component (module) structure of the examined software allows using the indicators, whose values depend on such structure and the reliability indicators of its particular elements.Depending on the method applied in that respect, it is possible to distinguish two approaches to the reliability modeling process, on the basis of: the structure set by the source code instructions, structure based on logical paths [6].
The models based on the architecture set by the source code for modeling the software architecture use the so-called control transfer graph, illustrating a possibility of transferring control between the blocks of the source code.The nodes on the structure are indicated by the so-called program control guidelines.It is often assumed in the models of the discussed class that the control transfer between them may be described by the Markov chains.This assumption means that the control transfer after implementation of a specific module to other modules does not depend on previous activation of the program blocks.The software architecture is modeled by the Markov chain, e.g.discrete in states and in time.
In the models based on the logical path concept, the software architecture is also created by separate blocks of the source code, e.g. by the modules, which are nothowever -analyzed as independent components, but as sequences of components executed one by one in case of activation of a given path by an appropriate set of input data.Knowing the values of the reliability indicators of the components that create a given logical path, it is possible to determine the value of the reliability indicator

2016
, 6 of the whole software, using the knowledge of the architecture of the software.The representative examples of the models based on logical paths may be found in studies [8,17,23].
It is worth mentioning that apart from the abovementioned methods for modeling the software reliability, models alternative to the models based on the software architecture and results of the software errors observed, e.g. during the software tests, are applied in practice.On such basis, the hypotheses concerning working time distribution between the moments of the occurrence of the two subsequent errors are formulated.The representative examples of such models may be found in studies [4, 10,12,14,20,22,24].
On the basis of the software engineering practice, it is evident that the software quality is the function of the time and expenses incurred during the production process, regardless of the applied methodology and production technology.Due to the fact that the process is usually executed with limited budget, the available funds should be used in a manner that maximally improves the quality of the produced software.A method often used in practice to achieve this objective is identification of the key components -for the purpose of proper functioning of the entire software -and paying special attention to the process of their production.It is worth mentioning that the solution of the issue of reducing the time and expenses required in the software production process may be significantly facilitated by applying formal methods of mathematical modeling and operational research.The examples of such approach may be found, for example, in [3][4][6][7]15,21].
The subject of the deliberations in this study is the allocation of funds for the production of the document management software, using the RFID technology, with a known component structure, assuming that the software production process covers independent production of its components.In further deliberations, the components of the discussed software will be called software modules or just modules.In accordance with the previous idea, the allocation of the aforesaid funds includes the impact of the particular modules on the correct functioning of the whole software.The model of the discussed software is the control transfer graph, in which the probability of activating particular component modules during the operation of the system results from the so-called operation profile of the software, characterizing its actual working environment.Identification of the modules, whose execution has the largest impact on the proper functioning of the entire software system, will be made on the basis of an analysis of the so-called software reliability structure, understood as the components.The optimum structure will be established as a result of the solution of a specific mathematical software task.The knowledge of the software reliability structure of the document management system, with the RFID technology, allows proper planning of time and expenses required for its production.It should be emphasized that the approaches found in the literature [1], for example to determine the meaning of particular component modules of the software, are based on the results of the socalled sensitivity analysis, i.e. the analysis of the impact of changing the values of the reliability indicators of particular modules on the value of the adopted indicator of the software quality.

Characteristics of the examined software
It is assumed that the examined software has a module structure, where the term "module" has the meaning generally given in the software engineering, i.e. a logically independent software component, which usually executes one function.The logical independence means, among other things, technological independence, i.e. the module may be designed, implemented and tested independently.The typical production process of the software with the above-described module structure consists in identification and separation of the component modules, independent performance of the individual modules and their subsequent integration (usually during the integration testing) into one.
For the purpose of this study, the analyzed software will be represented by the graph, with a set of vertices corresponding to the numbers of the selected component modules and a set of arcs, characterizing a possibility of transferring control between the modules during the execution of the software.Without compromising the deliberations herein, it is possible to assume that the discussed software has one input and one output module.In the literature, the graph with the provided values is called the control transfer graph of the software [1,16].
mean a set of the module numbers of the examined software, where -for the purposes of simplification -the input module has number 1, and the output module -number M. The reliability structure of the examined software will be understood as vector

R
, whose particular components are the reliability indicators of the component modules, where the reliability indicator of the module constitutes probability of its correct, single execution during the execution of the software.The execution of the software for the specific set of its input data consists in activating a certain, corresponding sequence of modules, which created the so-called logical path of the software.It is assumed that the measure of reliability of the examined software is probability of its proper execution for a single set of input data.The probability is equal to a product of probabilities of the proper execution of the modules, which are part of the path from the initial to the final module, activated by a given set of input data.The reliability of the software module is a function of many factors, such as qualifications and experience of its designers, applied production technology, amount of time and expenses incurred, etc.It is assumed in the study that the process of transferring control between the modules during the software execution is the Markov chain.In particular, it means that the probability of the ij p event consisting in the fact that after the execu- between the software component modules in the process of its execution results from the so-called operational profile of the software, characterizing its actual working environment.When adding to the software control graph two additional statuses corresponding to the proper and improper completion of the software execution, respectively, the Markov chain is obtained with two absorbing statuses, whereas -in accordance with the previous assumptions -the reliability indicator of the software, defined as the probability of its proper execution for a single set of input data, may be calculated as the probability of achieving by the discussed Marvov process the absorbing status corresponding to the proper and improper completion of the software execution.The examined Markov chain explicitly characterizes the transfer matrix, which -in accordance with the adopted assumptions -is of the form in which the first two lines and the first columns correspond to the proper and improper completion of the software execution, respectively, for a single set of input data.Let P(R) mean the matrix obtained by rejecting from matrix ) ( R P the first two lines and the first two columns.It may be shown that the reliability indicator of the software R(R) with reliability structure R, understood as the probability of its proper execution for a single set of input data, is defined by formula where M 1 S is an element located at the intersection of the first line and the M-th column of matrix S(R), defined in the following manner: where I is a unit matrix of the same category as matrix P(R).

Optimization of the software reliability structure
Let m K mean the cost of production of the m-th software component module, with the reliability indicator of m R , M m .
When assuming that the production costs of the particular modules are the known functions of their reliability indi- , it is possible to determine -by way of an appropriately formulated mathematical programming -the software reliability structure, which may be understood as a kind of the production plan, and form the practical point of view, especially two tasks might be useful: x one-criterion optimization task consisting in maximizing the value of the software reliability indicator as the function of objective, with the maximum, allowed cost of the software production being the limitation; x two-criteria optimization task, with the software reliability indicator and the cost of its production as the vector function of objective, ensuring determination of the allowed software reliability structure, i.e. ensuring achievement of the required, minimum reliability level and not exceeding of the maximum, allowed cost of the software production.
The knowledge of the optimum software reliability structure, at the stage of planning its production, allows to identify the modules of the greatest importance for the reliability of the whole software and hence allows to allocate the available funds in such a manner that the produced software fully meets the assumed reliability requirements.
When considering the introduced designations and assumptions made, the first of the aforementioned optimization tasks may be formulated in the following manner: The formulation of the second of the aforementioned optimization tasks may be in the following form: (R, F, < ), (5) where: Rset of allowed solutions, defined in the following manner: where valuesR(R), K(R) are defined in the following manner: <the dominance relationship is as follows: , whereY is the so-called criterial space defined in the following manner: The first of the formulated tasks is the one-criterion optimization.Its nature, and hence -the manner of solutionstrongly depend on the class (analytical form) of the

2016
, 6 software reliability indicator R(R) and the cost of its production K(R).The second of the formulated tasks is the non-linear two-criteria optimization task.Its solution may be determined in accordance with the generally adopted methodology for solving the optimization tasks [18].In accordance with this methodology, the solution of task ( 5)-( 9) may, in particular, require the determination of the following data: x set of dominating strategies, x set of non-dominated strategies, x set of compromise strategies.
Due to the nature of correlations (7), which define the component critertial functions ) ( R R and ) ( K R the subject task, it should be expected that the set of the dominant solutions would be empty.Therefore, in the discussed situation, the issue of determining the set of nondominated solutions and its potential narrowing, e.g. by setting the set of compromise solution, becomes of practical importance [18].The reliability structure * R , being the solution to task (3) -( 7), additionally maximizes the value of the software reliability indicator ) ( R R and minimizes the value of the function of the cost of ) ( K R its pro- duction.

Case study -software reliability of the document management system, using the RFID technology
The presented method for determining the software reliability structure will be illustrated by a number example, which is in accordance with the reality of the document management system software, using the RFID technology.The control transfer graph of the discussed software will be defined as in Fig. 1. , where module 1 is the initial module, and module 5 -the final module.The module structure of the software is defined by vector

R
. Let probabilities p ij of the control transfer between the modules, during the execution of the software be in the form of: Using correlation (1), the software reliability indicator with the reliability structureR may be defined based on formula , where value 15 S may be set on the basis of correlation (2) or programming package Mathematica [19], which allows performing symbolic calculations.
The use of the above-mentioned package for the module structure from Fig. 1 and the above-mentioned probabilities of transfers p ij provides the following dependency on probability S 15 For the purpose of formulating the previously discussed optimization tasks, it is assumed that cost K i (R i ) of the production of the i-th module with the reliability indicator R i is in the form of (11) where: KS i -fixed component of the production cost of the i-th module, independent of the level of its quality R i , D i , E i -co-efficient of the curve shape of the production cost of the i-th module, depending i.a. on its complexity, used technology, qualifications of the design and programming team, etc.
Let figures of value KS i , D i i E i and K max be defined as in Table 1.
For the module structure of the software in Fig. 1 and numerical data in Table 1, the solutions of the optimization tasks, formulated in the previous sub-chapter, i.e. the one-criterion optimization tasks (3) -(4) and polyoptimization tasks (5) -(9), will be determined.When using the possibilities created by modern computer technology, both tasks may be solved by the full review method.For that purpose, a set of all possible reliability structures will be created

Table 1. Figures of value KS
, to two decimal places.The number of vectors in this set is 6 5 =7776, out of which 7770 meet the restriction (4).
, where the cost of ) R ( K i i is defined in formula (11), for the most important (from the point of view of the solution sought) fragment of the above set of the reliability structures of the analyzed software.The lines corresponding to the forbidden solutions, i.e. vectors

R
, in case of which restriction (4) is not met, are marked in lighter color.Vector ) 00 .

R
is the optimum solution of the one-criterion optimization task (3) -(4).The corresponding line in table 1 was shaded.The value of the software reliability indicator corresponding to the optimum solution is R(R * )=0.87, with the production cost of the software K(R * )=158 481.43 €.
For the purpose of the analysis to obtain optimum solution R * , the sensitivity evaluation of the software reliability indicator was performed: R(R) with respect to a single change of the value of the reliability indicator of particular modules for the two levels of values of indicator R(R).The results are presented in Table 3.It is noticeable that the ratio of the growth value of indicator R(R) to the cost of its achievement is the least beneficial for module number 3. It means that increasing the value of indicator R 3 is the most costly.It is worth mentioning that this fact is reflected in the value structure of optimum solution R * .Due to the fact that the component criterial functions present in the two-criteria optimization task (5)-( 9) are of opposite nature (the cost of the software production is reduced, while the value of the software reliability indicator is maximized), the set of dominating solutions to this task is empty.Therefore, the solutions must be sought among the non-dominated solutions.To narrow the set to one solution only, the compromise solution, which is the closest (in terms of the Euclidiean space) to the so-called ideal point [18] will be indicated.For that purpose, both components of the vector criterial function )) R( ), (K( R R will be standardized, in result of which both indicators will have values in the range of [0, 1]: Table 5. Solution of the two-criteria optimization task K(R) d 160 000 €, R(R) t 0,8

Summary
The references include a description of the method for determining the optimum software reliability structure of a known module structure, assuming that the software production process covers independent creation of its component modules, where the software reliability structure is understood as the vector of the reliability indicators of the software component modules.The knowledge of the optimum reliability software structure allows proper planning of time and expenses required for the purpose of the software production, if the assumed reliability and cost requirements are met.The optimum reliability software structure is determined based on the solution to a specific one-or multi-criteria optimization problem.To establish the criterial functions or limitations of such mathematical programming problem, the program analyzed by the control transfer graph is modeled, where the probability of activation of the particular component modules in the software execution process result from the so-called operational profile of the software, which characterized the actual working environment of the software.Such graph model of the software allows, in particular, obtaining analytical dependency, defining the probability of the correct, single execution of the software on the basis of the Marvon chain theory.
The numerical example, which illustrates the abovedescribed deliberations, confirmed a possibility of obtaining the optimum reliability software structure by way of solving the mathematical programming problem, whereas -in accordance with the expectations -the structure, indicated as the solution to the on-criterion optimization problem, turned out to be the same as in case of the solution to the polyoptimization problem.

Figure 1 .
Figure 1.Control transfer graph of the discussed software According to Fig. 1, it is evident that the set of numbers of the modules of the discussed software is in the form of } 5 , 4 , 3 , 2 , 1 { M, where module 1 is the initial module, and module 5 -the final module.The module structure of the software is defined by vector) R , R , R , R , R ( i , D i , E i , K max used for calculations

Table 2 .
Solution of the one-criterion optimization task

Table 3 .
The unitary increase in the value of the software reliability indicator and the cost of its production for 'R