Subjectivity reducing in software version criticality classification with the support of an expert system

In the software version release management process, there is a need, on the part of human specialists, to classify the criticality of each software version. However, the subjectivity of this classification may be present according to the experience acquired by specialists over the years. To reduce subjectivity in the process, an Artificial Intelligence technique called Expert System (ES) can be applied to represent the knowledge of human specialists and use it in problem solving. Thus, the aim of this paper was to reduce the subjectivity in the criticality classification of the software version with the support of the Expert System. To this end, a questionnaire was developed with the objective of obtaining the criticality opinions classified as High, Medium and Low in each specialist's software version to assist in the preparation of the ES production rules. ES generated 17 production rules with a 100% confidence level applied to a production database. The results of the classification carried out by the ES corresponded to the classification carried out by the specialists in the production base, that is, the ES was able to represent their knowledge. Then, another questionnaire was applied to the specialists to verify the perception of satisfaction regarding the use of the ES with a result obtained of 4.8, considered satisfactory. It was concluded, then, that the ES supported the reduction of subjectivity in the classification of the criticality of software version.


Introduction
Information Technology (IT) has assumed a strategic role within organizations, supporting organizational processes in order to allow their execution in the best possible way, increasing competitiveness in a globalized market.
In order for this competitiveness to be achieved, it seeks to avoid loss of revenue, losses to the business and to guarantee the delivery of efficient and effective IT services that support business processes. (Arrivabene, et-al., 2021).
In this way, IT areas have used IT Service Management (ITSM) as an instrument for managing and controlling the computing environment, providing a proactive stance to meet the needs of the organization (Axelos, 2013) The ITSM is a set of organizational skills that promotes the integration of people, processes and technology, making them aligned with the organization's business strategy, thus providing value to organizations and the customers served by them (Barros & Salles, 2015).
Among the manageable IT services, there is the process of managing the release of hardware or software versions, which aim to build, test and deliver hardware or software services capable of supporting the specifications requested by the client, and deliver the desired results. by the organization (ITIL, 2013).
During the execution of the hardware or software version management process, key performance indicators or Key-Performance Indicators (KPIs) are generated, which help organizations to monitor the performance of the process execution, as well as to identify if there are quality in this execution (Cruz-Hinojosa & Gutiérrez-De-Mesa, 2016).
KPIs allow the development of a database with all the critical success factors of the process, being fed whenever the software version release management process is executed, thus creating a history of version releases (OGC, 2011) With the definition of KPIs it can be seen that the software versions have different criticisms, due to the difference in complexity that each software version can present in each release (Paschek, et al., 2016).
This criticality can be defined by the dependence that the components of the units and version release packages have on each other, and the consequences that the failure between these dependencies can cause to the business. In order to minimize risks in the release of software versions, it is necessary to establish methods for this purpose (Lee et al., 2018).
According to Jia, et al. (2018) the criticality of software versions can present risks to the business and must be classified objectively for the correct treatment of these risks. With the correct treatment of these risks, it is possible to improve the analysis of the criticality of the software versions, stipulate methods to reduce this criticality and studies on the prevention of the propagation of the occurrence of failures.
During the execution of the software version release management process, the criticality of a version is classified as High, Medium and Low. The classification of criticality in categories in a textual way, such as High, Medium or Low makes the perception of this criticality instantaneous to the recipient of this information. This technique of ordering descriptors that can be suggested as synonyms indicating criticality are often used in risk matrices (Napolitano & Sassi, 2018) This criticality, if classified incorrectly, can generate a subjective interpretation of the software version and thus, the misclassification of its criticality (Ferreira et al., 2016). This classification is performed by specialists, executors of the process, whenever a version is made available for release, however each specialist subjectively classifies it according to their interpretation of criticality based on their knowledge from the time of experience in the function (Ferreira et al., 2016).
Each specialist interprets the criticality of the software version according to their expertise in executing the process.
Its interpretation of which elements in a software version can be considered critical or does not generate divergence of opinions, so this variation can promote the imprecise classification of each software version (Monedero, et-al.,2008).
To reduce subjectivity in the classification of software versions in the software version release management process, an Artificial Intelligence (AI) technique can be applied, such as, for example, Expert System (ES) (monedero, et-al., 2008) According to Wagner (2017), ESs are knowledge-based systems for solving problems in a given domain, in the same way as human specialists. These knowledge-based systems are structured through a knowledge base, an inference engine, and an interface.
With the software version release management process being executed accurately, KPIs are generated to identify the critical success factors that allow to classify the criticality of the software versions. With the support of ES, subjectivity in the classification can be reduced.
Thus, allow alignment with the results expected by the organization. The aim of this paper was to reduce the subjectivity in the criticality classification of the software version with the support of the Expert System.
The study that addressed the treatment and reduction of subjectivity is considered as the main contribution of this work, which, in general, affects organizational processes by hampering decision making.

Version Release Management Process
The version release management process has the purpose of identifying the criticality of a release package, or of a release unit, which is a component of a release package both in the approval environment and in the production environment, however attention should be paid to the critical subjectivity of this identification.
Identifying and classifying this criticality is necessary, and establishing methods for doing so meets this need. Heeager and Nielsen (2018) point out that due to the increased complexity of software versions, understanding and evaluating their criticality cannot be ignored.
The version release process consists of two elements: Version Release Units and Version Release Packages. These version units and packages can be released by classifying the version release type, shape and mechanism (ITIL, 2013).
In the software version release process, the terms "Release unit" and "Release package" are defined as follows (Durkin, 1994). a) Release Unit: small amounts of software that are released according to the need for patches or new implementations of a system, which can be just a module or an entire system. Research, Society andDevelopment, v. 11, n. 1, e37811125132, 2022 (CC BY 4.0) | ISSN 2525-3409 | DOI: http://dx.doi.org/10.33448/rsd-v11i1.25132 4 b) Release Package: Set of release units or even a single unit, however larger. A new version of software may be released containing the new executable, object, database scripts and user manuals, for example. This set is a release package. Figure 1 shows the graphical representation of Units and Release Packages. According to Figure 1, the components of a release are described as follows: a service called A when made available may consist of two applications called A1 and A2. The A1 application consists of two software modules called A1.1 and A1.2. A best practice in the version release management process to control the execution of the process and obtain information about the performance of the execution and its quality is the elaboration of Key Performance Indicators (KPIs) (OGC, 2011).
During the execution of the software version release management process, the following indicators can be used as KPIs can be organized in databases that allow the measurement of quality and the ability to execute the software management process. Thus, allowing to classify the criticality of a software version released by the release management process, through strategic KPIs, allowing decision making regarding the results of the execution of this process (Paschek, etal., 2016).

Expert Systems
According to Wagner (2017), Expert Systems (ESs) are based on knowledge to solve problems in a given domain in the same way that human specialists would solve.
ESs have been applied since the 1970s to solve problems in several areas. This can be seen in the work of Wagner (2017) who carried out robust research collecting 311 case studies related to the application of SEs between the years 1984 and 2016. In the research, the diversity of applications ranges from accounting services, aerospace industry, area of transport to the health area, which shows the relevance of the application in several types of problems (FARIAS et al., 2021).
However, SEs when applied to software have their research concentrated in the Engineering area (Rezende, et-al., 2019). There are few studies that deal with the application of ESs in reducing subjectivity. The following works that deal with subjectivity can be highlighted: Lee et-al. (2018), development of a simulation-based test environment for security-critical software; Khan et-al. (2011), Knowledge-Based System Modeling for Software Process Model Selection; García-Valls et-al. (2018), an extensible collaborative framework for monitoring software quality in critical systems and Babar et al., ES for a scalable software requirements prioritization process.
It is noteworthy that, in the bibliographic survey carried out, no work was found, which reduced subjectivity in the classification of the software version criticism with the support of an ES, which demonstrates the importance of this work.
To represent the knowledge of human specialists, the ES must have not only a set of information, but also the ability to use it in solving problems. This skill represents a series of intuitive rules that the specialist uses to solve problems, and its application makes it possible, in a more economical way, to obtain acceptable, although not always optimal, solutions (PANNU, 2015).
ESs must also have the ability to learn from experience and explain what they are doing and why they are doing it, thus taking powerful training, instruction and education tools (Castelli, et-al., 2017).
ESs can be classified according to the class of tasks and / or problems for which they are developed: Interpretation, Diagnosis, Monitoring, Prediction, Planning, Project, Debugging, Repair, Instruction and Control (Durkin, 1994).
The basic structure of an ES is made up of three fundamental elements: Knowledge Base, Inference Engine and User Interface. This basic structure is represented in Figure 2. The following are the three fundamental elements of the structure of an ES. a) Knowledge Base: It can be defined as the repository for storing all the data and / or information necessary to solve a certain problem. This knowledge is classified into facts and rules, or another type of representation, such as: mathematical logic or semantic networks (Wagner, 2017). This is not a simple collection of information. The traditional database with data, files, records and their static relationships are here replaced by a base of rules and facts and also heuristics that correspond to the knowledge of the specialist, or the specialists of the domain on which the system was built (Durkin, 1994). Durkin (1994) explains that within the knowledge base: -The Facts Base: It represents the knowledge that is initially known and that can be considered as a starting point for solving the problem. They are also characterized as knowledge in the public domain, easily accessible and that can be extracted through texts, manuals, standards, books, fact finding and results of experiments; -The Rules Base: Represents the knowledge that is extracted directly from the experts. This knowledge represents the "knowledge developed by the specialist (heuristic), based on the facts already known and the deductions from them. Here, the term "heuristic" means the skill, or the simplification used by the specialist in order to optimize the search for the solution of a problem.
In this way, new knowledge can be added to the knowledge base, enabling the ES to make a decision on the problem.
The representation of knowledge by rules aims to produce a general computational model of problem solving (Roldán-García, et-al., 2017).
The representation of knowledge by production rules is used in ESs. The justification is the naturalness that it represents for man, because the condition-action pair to reason and decide is also used by human beings. The degree of confidence is a percentage indicating the reliability of the conclusion of the rule, which can vary from 0% to 100% (Dymova, et-al., 2016) The final structuring of the production rules is based on the IF ... THEN model, unifying the structure of the premises with the structure of the conclusion, as in the following example: SE <ATTRIBUTE 1> = <VALUE> AND <ATTRIBUTE 2> = <VALUE> THEN <ATTRIBUTE COMPLETION> = <VALUE> <DEGREE OF CONFIDENCE%> b) Inference Machine (IM): Contains an interpreter who decides how to apply the rules to infer new knowledge, in addition to a priority list of application of these rules.
It implements ways of reasoning, techniques and search strategies, conflict resolution and treatment of uncertainty.
Basically, IM performs two main functions: Interpreter / Inference: Based on the knowledge contained in the knowledge base and in the working memory, the IM determines which rules must be triggered to infer new knowledge. The IM determines or schedules the order in which the rules should be applied (Durkin, 1994).
IM is an essential element for the existence of an ES composing the core of the system. Through it, the facts, rules and heuristics that make up the knowledge base are applied in the problem-solving process. c) User Interface: It consists of the components that allow the system to communicate with the knowledge engineer and the end user and that is easy to navigate and understand. The characteristics of the interface are directly related to the type of problem under consideration (Liao, 2005).

Methodology
The research methodology adopted was defined as applied research, since it aims to generate knowledge for solving problems, thus having a practical application. From the point of view of its approach, it is of a qualitative nature, whose research environment had as a direct source the data collected. Experimental research is also present, as it determines an object of study, the variables that would be able to influence it are selected, the ways of controlling and observing the effects that the variable produces on the object are defined (Yin, 2016).
The bibliographic survey was carried out in consultation with articles, books, theses, dissertations and websites related to the following terms: Specialist Systems, Software Version Release and Key-Performance Indicators.
The company Softplan offered corporate support for the development of this work by authorizing the disclosure of its name and the use of data related to the software version release process in the period between January 2017 and December 2018. The research was developed taking as based on the software version release management process for applications in the area of judicial automation, referred to as First Degree, delivered to its main customer in São Paulo with a number of users exceeding 70,000 (Softplan, 2021).
The production database was used to perform the computational experiments covering the period from January 2017 to December 2018, containing 423 records and 16 attributes. A production database is used to record the data related to the software version release packages when they are approved and then distributed in production, this being the final environment that will use the software version.
It is worth mentioning that before the computational experiments were carried out with the production base, experiments were carried out with the homologation base, which contains 628 records and 11 attributes, that is, less in number of attributes than the production base. This experiment was carried out with the objective of verifying whether an ES could be applied on a basis with characteristics similar to the production. The results obtained were positive, but were not presented in this work because the focus was on the production base.
A homologation database is used to record the data related to the software version release package when they are released by the development team, being distributed on an homologation basis for version testing.
The hardware used to perform the computational experiments was a 2.80 GHz Intel Core i7-7700HQ Quad Core computer with 16 GB of RAM, 1TB of hard disk and 64-bit Windows 10 Pro operating system. The software used was ExSinta Version 1.1, a visual tool for creating Expert Systems (LIA, 2017).

Expert System Development and Application Phase
It is worth mentioning that the software version management environment was structured after the application of the following techniques and methodologies: Business Process Management (BPM), Information Technology Infrastructure Library (ITIL), Six Sigma Methodology and Project Management Body of Knowledge (PMBOK). The focus of the work is the application of ES, therefore, the application of techniques and methodologies has not been described.
The software version criticality classification is analyzed and interpreted by the specialists who execute the process, making the version criticality analysis a subjective activity, making the decision-making process more difficult. This subjectivity is due to the fact that experts have divergent opinions on the criticality of each software version. from previous experiences.
In order to reduce subjectivity in the execution of the software version release management process and to promote more accurate decision-making, ES was developed and applied. Research, Society andDevelopment, v. 11, n. 1, e37811125132, 2022 (CC BY 4.0) | ISSN 2525-3409 | DOI: http://dx.doi.org/10.33448/rsd-v11i1.25132 8 The steps presented in Figure 1 are described below: -Step 1: the AI technique was defined, the ES as the technique to be applied to reduce subjectivity in the software version classification. For the development of the ES, it was necessary to establish a way to obtain the knowledge of the specialists. For this, each specialist was asked to assign a degree of criticality to each of the six scenarios, considering the type of release and the category of release of six execution scenarios. This assignment was called a questionnaire. Table 1 characterizes the specialist's role and his / her experience in working in the area. Source: Authors. - Step 2: five employees of the software development company participated in the application of the questionnaire: a team coordinator and four systems analysts. The proposal for applying the questionnaire for each scenario, aimed to obtain opinions that were used for the elaboration of the ES production rules. Table 2 shows the six scenarios of production release packages in production.  Table 3 is the sixth scenario regarding the Release Type: Client / Server (EST) and the Release Category: Correction / Implementation.  Step 5: In a new meeting with the experts, the ES rules were tested and validated by the experts.
-Step 6: ES was applied to the production database.
-Step 7: for the validation of the results presented by the ES on the production base, that is, if its rules are reliable, a comparison with the classification made by the experts on the same basis was proposed (Geissman & Shultz, 1988).
-Step 8: a questionnaire with five closed questions based on the Likert Scale (Likert, 1932) was applied to the specialists in order to obtain the final perception about satisfaction in relation to the use of the ES, evaluating its interface and usability.

Results and Discussion
Is it presented below in the Number tables? up number? the results obtained from the experts' consensus regarding the six execution scenarios, after the application of the questionnaire.  Research, Society and Development, v. 11, n. 1, e37811125132, 2022 (CC BY 4.0) | ISSN 2525-3409 | DOI: http://dx.doi.org/10.33448/rsd-v11i1.25132 Table 5 shows the model of criticality for the scenario of software version release Type Client Release Category Correction in Production.        Table 9 shows the model of criticality for the Scenario of software version release Type Client / Server EST Release Category Correction / Implementation in production. The number of production rules generated by the ES was seventeen (17). Table 10 shows an example of a rule and its characterization.
Table 10: Example of characterization of a production rule generated by the ES for the production base.

Rule 1 Characterization ES Release Type = Server
Defines within which Scenario the inference will be made AND 1_Number of Accumulated Versions = 1 till 3 Defines the Number of Versions to be released AND 1_Number of PG5 Bases Updated = 1 Define the Number of PG5 Bases that will be updated OR 1_Number of PG5 Bases Updated = 2 till 23 OR 1_Number of PG5 Bases Updated = 24 or more AND 1_Number of Objects PG5 Server = 1 till 3 Defines the Number of Objects PG5 to be distributed AND 1_Number of Objects NET Server = 1 till 3 Defines Three examples of production rules generated by the ES are presented below.

Rule 2
IF Release Type = Client AND 2_Number of Accumulated Versions = 1 till 3 ND 2_Number of PG5 Bases Updated = 1 OR 2_Number of PG5 Bases Updated = 2 till 23 OR 2_Number of PG5 Bases Updated = 24 or more AND 2_Number of Objects PG5 Client = 1 AND 2_Number of Objects NET Client = 1 AND 2_Number of Objects IND Client = 1 AND 2_Number of Objects Extras = 1 AND 2_Number of Objects PSS Client = 1 AND 2_Number of Scripts PG5 Master = 1 till 10 AND 2_Number of Scripts PG5 Master / Destination = 1 till 10 AND 2_Number of Scripts NET = 1 till 5 AND 2_Number of Scripts IND = 1 till 5 Research, Society and Development, v. 11, n. 1, e37811125132, 2022 (CC BY 4. Table 11 presents an example of the Production database for the period from January 2017 to December 2018 containing the rating of criticality performed by the human specialist before the consensus, the rating of criticality performed by the human specialist after the consensus and the criticality classification carried out by the ES for the purpose of comparison. In relation to Table 11, the divergent classifications among human specialists before and after the consensus and the classification carried out by the ES stood out in yellow. Based on the results in Table 14, it was observed that of the 275 classifications performed by the specialists, 62 presented divergences in the classification performed by the specialists before the consensus and after the consensus. It was also observed that the classification issued by the ES corresponded to the classification of the specialists after the consensus.
The results are presented in Table 12, considering the equalities and divergences in the criticality classification of the software version, between the specialists before consensus and the ES, in the period from January 2017 to December 2018. Evaluating the results of the divergences in the software version criticality classification with the production database, shown in Table 15, it was observed that the Scenarios Client / Server Implementation and Server presented an MEDIUM of 50% divergence in the classification among experts before consensus and in ES classification.
These divergences characterize the subjectivity in the analysis of each version by the specialists, who even with simpler release packages had different classifications before the consensus in relation to the ES.
Regarding the comparison between the results of the experts 'classification after the consensus with the results obtained by the ES, it can be observed that the ES continued to present classifications that reflected the experts' knowledge after the consensus. In Step 8, a questionnaire was applied to specialists in order to obtain the final perception about satisfaction in relation to the use of the ES, evaluating its interface and usability, as well as the results of the criticality rating of the software version obtaineds. Table 13 presents the results of the questionnaire on the satisfaction of using the ES in the production base. During the experiments, was it easy to understand the usability and navigation between the ES screens? 5 5 4 5 4 During the experiments with the Production Database, did the ES results meet your expectations? 5 5 5 5 5 At the end of the experiments with the ES, did your perception on the use and results obtained demonstrate a reduction in subjectivity in the classification of software version? 5 5 5 5 5 Source: Authors.
Analyzing the results of the questionnaire, the following expert opinion was obtained, as shown in Table 14. Based on the results presented in Table 18, it was observed that the evaluation of the ES by the specialists met the expectations regarding the interface, the use, and the reduction of subjectivity in the classification of software version.

Conclusion
To reduce subjectivity in the opinion of human experts regarding the criticality of the software version, the development and application of an ES was proposed. Thus, when applying ES in the classification of software version in the production database, the results obtained were consistent with the classification after the consensus made by human specialists on criticality. There was a reduction in subjectivity in the process.
The results of the software version classification issued by ES were validated when compared with the classification results after consensus by human specialists. It is concluded that the general objective was achieved by reducing subjectivity in the criticality classification of software version with the support of ES.
The study that addressed the treatment and reduction of subjectivity is considered as the main contribution of this work, which, in general, affects organizational processes by hampering decision making.
In the academic field, this research contributed to the academic literature on the subjectivity reduction subject, using an AI technique in the software version release management process.
At the corporate level, this research shows the practical application of methodologies and good practices in process management, IT and projects applied in an aligned and integrated manner, together with the application of an AI technique, considered in this scenario as an emerging technology, and a differential for more objective decision-making processes.
In the social sphere, the fact that this research was carried out in the corporate environment of a software development company, which provides services to customers who effectively work with social welfare, provided a maturity in the execution of the version release management process. software, reducing the unavailability of the systems used for this purpose.
Consequently, the end users of the applications of this client of the software development company have benefited from the decrease in the unavailability of the systems, which play an important role in the provision of judicial services to society.
The application of another AI technique, Case Based Reasoning (CBR), is indicated as a continuation of the research when considering the release package scenarios as cases on a case basis that would be updated automatically.