On the application of a model for assessing the transactional reliability of information systems of industrial enterprises

The article examines an example of the application of a model for assessing the transactional reliability of information systems of industrial enterprises. This transactional reliability determines the correctness of the calculations performed and the integrity of the data, and, consequently, the characteristics of the quality of software tools that are used in information systems of industrial enterprises to perform control and data processing functions. It is shown that all the parameters of this model can be obtained from the results of testing the system, which makes it possible to construct adequate estimates of the reliability parameters. The calculated indicators obtained using the developed model differed from the real ones by no more than 5%, which indicates the sufficient adequacy of the model. The modern system Microsoft Dynamics 365 for Finance and Operations (Dynamics AX/Axapta) was used as an environment for modeling and analyzing the transactional reliability of software tools.


Introduction
When developing critical projects of information systems of industrial enterprises, developers try, to one degree or another, to obtain an assessment of the reliability of software. This is usually done based on the final test results of the system. However, modern software used in complex information systems uses a colossal amount of data in its work, passing through standard modules and functions. Therefore, it is almost impossible to identify all the connections and ways of information processing, even for a fairly simple program. Based on this, the detailing of the elements (conditionally called software modules) of the reliability calculation should be limited to complete software components. These components, interacting with each other, constitute a more complex combination, for which we need to calculate the operational (hereinafter referred to as "transactional") reliability.
Currently, transactional information processing is becoming one of the most important aspects that determine the correctness of calculations and data integrity, and, consequently, the characteristics of the IOP Publishing doi: 10.1088/1757-899X/1155/1/012064 2 quality of software used in control and information processing systems [1][2][3][4]. The large number and ever-increasing complexity of software tools for transactional information processing require increased attention to transaction modeling throughout the development process. The transactional computing model implemented in a software tool essentially determines whether the software tool will be in a consistent state and maintain the required level of system reliability.
The main advantage of this model is that all the parameters of this model can be obtained from the data after the system test, which makes it possible to construct estimates of the reliability parameters [5][6][7].

Information systems of industrial enterprises
Such a model is useful for evaluating information systems for processing and storing data, for example, for modern Enterprise Resource Planning (ERP) systems [8]. These systems allow not only to maintain operational (goods, services, production), financial, tax accounting at the enterprise, but also allow the management, the planning department to build budgets and monitor their implementation, plan the activities of the enterprise, manage the enterprise, analyzing the planned and actual indicators in the system.
Systems of this class are more focused on working with financial information for solving problems of managing large corporations of various types of activities with geographically separated resources. This includes everything that is necessary to obtain resources, manufacture products, transport them and settlements for customer orders. In addition to the listed functional requirements, ERP implements new approaches to the use of graphics, the use of relational data, CASE-technologies for their development, architecture of computing systems of the "client-server" type and their implementation as open systems.
ERP is a methodology aimed at efficient management of all production resources of an enterprise [9]. It provides a solution to the problems of planning the activities of the enterprise in physical and monetary terms, modeling the capabilities of the enterprise. This methodology is based on a number of large interrelated functionalities, including: An enlarged ERP management structure is shown in figure 1. The presence of a powerful infrastructure and methodology for building systems contributes to the achievement of a high level of efficiency in the implementation of management systems such as ERP in industrial enterprises. According to some estimates, the introduction of such systems can lead to a reduction in stocks up to IOP Publishing doi:10.1088/1757-899X/1155/1/012064 3 30%, an increase in labor productivity up to 25%, an increase in the number of orders completed on time, up to 20%.

Dynamics AX / Axapta
The modern system Microsoft Dynamics 365 for Finance and Operations (Dynamics AX/Axapta) was chosen as an environment for the development of a system of model-algorithmic support for analyzing the transactional reliability of software tools. This is an automated enterprise management system that provides the management of the company and its employees with the most complete information necessary for a successful business.
Dynamics AX is a scalable system for midsize and large enterprises, corporations and holding structures, providing a single, integrated solution aimed at increasing business manageability and increasing enterprise profits.
Dynamics AX is a powerful tool that realizes opportunities for both operational operation of the enterprise and for the formation of a long-term strategy, which allows you to lay the foundation for successful operations.
The uniqueness of the Dynamics AX system is in its modern advanced technology, which provides a single information space for the enterprise. Powerful functionality, optimal price / quality ratio, ease of learning, ease of use and configuration of the system make it possible to build an information management system at an enterprise that corresponds to its industry and individual characteristics. • Dynamics AX system is written in the object-oriented language X ++, similar in syntax to C ++ and Java; • Dynamics AX system has an open source code available for modifications; IOP Publishing doi:10.1088/1757-899X/1155/1/012064 4 • Dynamics AX system has built-in visual programming tools; • Dynamics AX system has about 2000 classes that implement the business logic of the system; • Dynamics AX system has a built-in code profiler with run-time granularity down to a line of source code; • Dynamics AX system has built-in tools for monitoring and tracing errors; • Dynamics AX system has the ability to organize distributed computing.
The system of model-algorithmic support for the analysis of transactional reliability of software is implemented as a module "Reliability Models" of the ERP-system Dynamics AX.
The logic of the system of model-algorithmic support for the analysis of transactional reliability of software is written in X ++ in the form of a class hierarchy and is integrated into the logic of Dynamics AX [8,9]. Final and intermediate results are saved in the database for further analysis. The module is built as a set of dialog boxes and reports for interactive interaction with the user [10]. The user can create new parameters for the model, adjust existing parameters, make calculations of reliability parameters, save results and build reports on already performed and saved calculations. After opening the module, the user can configure the main reference books of the module: parameters of class descriptions, descriptions of transactions. After choosing a model for assessing transactional reliability, the user must fill out reference books about the classes used or transactions included in the calculations, as well as operational profiles based on the test results. Calculations are performed automatically and controlled by the user. The entered and calculated data are saved in the database. The results of past calculations can be printed using reports.

Model for assessing the transactional reliability of information systems
Reliability of software is defined as the probability of functioning without errors for a certain period of time in a particular operating system. For most developers, reliability is defined as the correctness of the software, i.e. the number of errors to be corrected during the test.
Transactional reliability differs in its meaning from the classical understanding of reliability. It can be used to assess the reliability of software for processing and storing data, where the logical unit of work is a transaction [11].
Transactional reliability depends not only on the reliability of the components, but also on the specific problem area for which the software was developed, formally -on the set of operational profiles of the components. An operational profile is a set of disconnected and non-overlapping input ranges and the probabilities of their use by components. Profiles may differ for different operating systems. Obtaining an operational profile requires dividing the input range space into subsets (leaves), and then estimating the probabilities of using each subset (leaf). A subset with a sufficiently high probability of use can be divided into smaller zones. Profiles are tables that include information about the ranges of the input data of the module and the probability of failure on a given range of data [2][3][4].
To calculate the overall transactional reliability Rtr, it is necessary to compile a complete list of all transactions and calculate the reliability of each transaction using the operating profiles.
A transaction is a sequence of actions that is considered completed successfully if there were no failures at any step. A transaction can be either a single transaction of information systems, or a certain, logically completed, independent sequence of user actions in the system. For correct calculations, you must select one type of transaction.
Let PUjthe probability of using the j-th transaction, where ∑ =1 = 1; Rtjreliability of the j-th transaction; Rtrtransactional reliability of the system.
The weight (reliability) of the i-th class of the j-th transaction is determined by the formula: The reliability of a transaction can be calculated as: After calculating the reliability of all transactions, the total transactional reliability of the system is calculated: (3)

Results
As an example, consider the "Master Planning" module of the Dynamics AX system, implemented at the enterprise of the Krasnoyarsk Territory in the «FORS» company [6]. As a result of testing, 4 transactions were identified, which in total use 18 classes with a maximum number of input ranges of 4. Table 1. Operating profiles of classes.

Classes (Ki)
Failure probabilities in the range The probabilities of using transactions are: The vectors of the probability of using the ranges and the vectors of the weights are as follows (see table 2).
The vectors of the probabilities of using the ranges and vectors of weights of transactions T2, T3 and T4 are formed in a similar way.

Discussion
Analyzing the calculation results, we conclude that when working with these types of documents (four types of transactional data processing), the system will fail in 351 cases out of 106, provided that the operator does not make mistakes. As a result of the real test, according to which the above calculation was made, out of 106 transactions, 338 transactions were unsuccessful.
The value of the experiment lies in the fact that both classes and their input ranges were identified that contribute the most to the probability of failure. This allowed us to pay more attention to testing and identifying errors in the code and in the "blockage" of the system under test.
The greatest weight in the probability of failure is made by the classes: K7, K10, K14. By reducing the probability of failure on input ranges in these classes by half, you can achieve the following results: • Rt1 = 0.999564; • Rt2 = 0.999855; • Rt3 = 0.999784; • Rt4 = 0.999860.
As a result, we get a new transactional reliability of the system Rtr = 0.999750.

Conclusion
During the full system testing phase, you can find the blockage in the system -those components that contribute the most to the likelihood of failure.
By knowing exactly which operating profiles and input ranges are most likely to fail, we spend less time finding and fixing bugs in our code.
For a ready-made system for processing and storing information with specified operating profiles, it is possible to calculate the final transactional reliability and system availability, as well as track their changes in the course of eliminating errors in the blockage.
As a result of using the system in a real project, it was possible to identify the blockage in the system and improve the reliability indicators. The calculated indicators obtained using the developed models differed from the real ones by no more than 5%, which indicates the sufficient adequacy of the model.