Method of Developing the Defect-Free Medical Software by Establishing the Presence of Residual Defects Tetiana Hovorushchenkoa, Peter Popovb a Khmelnytskyi National University, Institutska str., 11, Khmelnytskyi, 29016, Ukraine b City University of London, Northampton Square, London, EC1V 0HB, United Kingdom Abstract The actual task is to develop the defect-free medical software by establishing the presence of residual defects, and the purpose of this study is to develop an intelligent method & system of developing the defect-free medical software by establishing the presence of residual defects. The paper develops a method of developing the defect-free medical software by establishing the presence of residual defects, the essence of which is to identify the set of defects of different levels of criticality and analysis of this set for the presence or absence of residual defects. The method differs from the known ones in that the input information about the results of the basic testing is processed by an artificial neural network. The proposed system of developing the defect-free medical software by establishing the presence of residual defects allows the user to obtain a conclusion about establishing the presence or absence of residual defects (indicating the level(s) of criticality of residual defects in case of their presence) based on the processing of information on the number and types of defects detected during the basic testing contained in the basic test report. On the basis of heuristic estimates, the threshold values of the number of defects of each criticality level are defined, after exceeding which a conclusion is made about establishing the presence or absence of residual defects (indicating the criticality level(s) of residual defects in case of their presence). In general, the proposed system allows the development of defect-free software by detecting residual defects in medical software after the basic testing, thereby increasing the veracity of testing and, accordingly, increasing the quality of medical software. Keywords Software, medical software, software defects, minor software defects, moderate software defects, serious software defects, catastrophic software defects, residual software defects, defect-free medical software. 1. Introduction & State-of-the-art The density of defects in software of different sizes is represented by a diagram (Figure 1), which shows the typical density of defects per 1000 lines of code for software of different sizes [1-6]. Figure 1 shows that software, which has millions of lines of code, cannot be defect-free at this time. The task of the developers in this case is to ensure the required quality and reliability of the software, taking into account that the software has some unknown number of residual defects that should be identified and blocked or their impact should be reduced to an acceptable level. Types of software defects: defects in the formation of the software requirements [7-9], defects in software coding [10], defects in software testing and verification [11], defects in software development planning [12], defects in software design [13, 14], defects in software development management [15]. Defects remain in the software even after testing due to objective (imperfection of testing methods and incompleteness of tests, lack of funds for testing, etc.) and subjective (insufficient qualification of IDDM-2021: 4th International Conference on Informatics & Data-Driven Medicine, November 19–21, 2021, Valencia, Spain EMAIL: tat_yana@ukr.net (T. Hovorushchenko), p.t.popov@city.ac.uk (P. Popov) ORCID: 0000-0002-7942-1857 (T. Hovorushchenko), 0000-0002-3434-5272 (P. Popov) ©️ 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings (CEUR-WS.org) software developers and testers, the impact of their inherent subjective shortcomings, etc.) factors [16- 19]. Such defects are referred to as residual defects. 100 90 80 70 60 From 50 Till 40 30 20 10 0 <2K 2-16 K 16-64 K 64-512 K > 512 K Figure 1: Diagram of typical defect density per 1000 lines of code for software of different sizes Residual defect is any software defect that remains in the software product after its testing and debugging. Residual defects differ from those detected in that they at a certain point in time after testing and debugging the software exist and have not yet been identified. The presence of residual defects in the software can lead to faults and failures, accidents and catastrophes, the consequences of which are financial losses, information losses, reputational losses, and even human losses. As a result of the manifestation of residual defects, the following negative events have been occurred: 1. Due to a large number of residual defects in Shadow's automated internal voting system software, the US Democratic Party was unable to vote in 2020, that completely undermining its reputation and credibility in the US market [20]; 2. Residual defects in the software led to failures in British Airways' information systems for online check-in and flight services during flights in 2019, as a result of which British Airways canceled 117 flights at Heathrow Airport, 10 – at Gatwick Airport; the loss exceeded $ 200 million [21]; 3. Due to residual software defects in the automated system timing, Boeing's first Starliner CST- 100 spacecraft in 2019 started engines ahead of schedule and burned excess fuel, because of what the spacecraft from entering orbit and docking to the International Space Station [22]; 4. Residual defects in the software led to the inability to collect debts on loans and could lead to a loss of revenue of Provident Financial in the amount of $ 158 billion in 2018, due to which the value of shares of the British financial company Provident Financial fell by a total of $ 2.2 billion [23]; 5. In 2018, in the United Kingdom, 709000 medical records were not delivered to patients or their therapists due to residual defects in the software, resulting in 1,700 cases where untimely data led to a serious deterioration in patients' health [23]; 6. Residual defects in the software led to an increase in prison terms ranging from 0.5 to 1.5 years in the United States in 2018, as a result of which hundreds of prisoners filed lawsuits [23]; 7. In 2017, a residual defect in the software was found in Fiat Chrysler trucks, which temporarily disabled the airbags and seat belts, resulting in a fatal accident, and Fiat Chrysler withdrew 1.25 million trucks already sold. On the one hand, the annual increase in the number of lines of program code [25], and on the other – the increase in the number of news about software defects [26], gives the right to argue the potential increase in the number of residual software defects. Even more residual defects remain in multidisciplinary medical software, which is developed at the intersection of the medical domain and software engineering domain, when there is a different understanding of the context of information, the need to consider both software development standards and standards of the medical field [2, 6]. Since both the veracity of testing and the quality of software depend on the number of defects found in it, including residual, the increase of the veracity of testing and, accordingly, the quality of software can also be achieved by developing the defect-free software by detecting residual defects in software after basic testing. Then actual task is to develop the defect-free software by establishing the presence of residual defects, and the purpose of this study is to develop an intelligent method & system of developing the defect-free software by establishing the presence of residual defects. 2. Concept of Developing the Defect-Free Medical Software by Establishing the Presence of Residual Defects Let's clarify the distribution of the type of software defects to form a conclusion about the presence or absence of residual software defects. All software defects are divided into minor, moderate, serious and catastrophic. Minor software defects will be such defects that do not affect the user's actions, the software with their presence is suitable for use. Moderate software defects are considered to be such defects that affect the user's actions, but the software with their presence is still suitable for use with partial loss of functionality. Serious software defects will be considered such defects that lead to erroneous results, as a result of which the software is already unusable. Catastrophic software defects will be considered such defects that lead to distortion of information (data), as a result of which the software is unusable and an attempt to use it leads to system failure. Minor defects are assigned the lowest criticality level – the first. Moderate defects are assigned, respectively, the 2nd criticality level; serious – the 3rd criticality level. The highest criticality level is assigned to catastrophic defects – 4th level. The accumulation of a certain number of minor defects leads to the appearance of moderate defects, the accumulation of a certain number of which, in turn, leads to the appearance of serious defects, the accumulation of a certain number of which, accordingly, leads to the appearance of catastrophic defects. This is justified by the fact that the longer the defect is in the software development cycle, the more it penetrates into all software components and the more damage it causes at all stages to all components. Thus, defects of one level of criticality can be the cause of residual defects not only of the next level of criticality, but also of residual defects of higher levels of criticality. In this case, we introduce a threshold of the allowable number of defects, above which it is necessary to conclude that the presence of residual defects of the next level of criticality. The initial data for forming a conclusion about the presence or absence of residual defects of a certain level of criticality is information about the number and types of defects detected during the basic testing, i.e. the report on basic software testing. Finding as many residual defects as possible will increase the veracity of the testing process and, accordingly, the quality of the software, which, in turn, will make it possible to develop the defect- free software. The concept of developing the defect-free medical software by establishing the presence of residual defects using an artificial neural network (for solving the difficult-to-formalize problem of determining the importance and criticality of software defects and their mutual influence, vagueness of initial data about existing defects, etc.) is presented in Figure 2. Figure 2: Concept of developing the defect-free medical software by establishing the presence of residual defects 3. Method & System of Developing the Defect-Free Medical Software by Establishing the Presence of Residual Defects For describing the rules of forming a conclusion about establishing the presence of residual defects, we enter the threshold ri  R ( R  { r j | j  1..k } , where r j – the threshold of the allowable number of defects, exceeding of which leads to the conclusion is formed about the presence of residual defects, j – the number of criticality types varying from 1 to k , k – the number of criticality levels of defects (i.e. now k  4 )). The general rule. If the ratio of the total value of defects of the i -th criticality level to the total number of defects detected during the basic testing (or the total value of defects of the i -th criticality level) exceeds the threshold ri , it is concluded about establishing the presence of residual defects ( i  1 ) -th (next) criticality level. The following specific rules of forming the conclusion about establishing the presence of residual defects follow from the general rule: 1. If the ratio of the total value of defects of the 1st level of criticality (minor defects) to the total number of defects detected during the basic testing is equal to or exceeds the threshold r1 , it is concluded about establishing the presence of residual defects of the 2nd criticality level (moderate defects). 2. If the ratio of the total value of defects of the 2nd level of criticality (moderate defects) to the total number of defects detected during the basic testing is equal to or exceeds the threshold r2 , it is concluded about establishing the presence of residual defects of the 3rd criticality level (serious defects). 3. If the total value of defects of the 3rd criticality level (serious defects) exceeds the threshold r3 , the conclusion is made about establishing the presence of residual defects of the 4th criticality level (catastrophic defects). 4. If the total value of defects of the 4th criticality level (catastrophic defects) is equal to or exceeds the threshold r4 , then a conclusion is made about the unsuitability of the software and the possible failure of the system. Method of developing the defect-free medical software by establishing the presence of residual defects consists of the following steps: 1. Based on the results of the artificial neural network (ANN) the set D  { d i | i  1..4 } is formed, where d i – the total values of the defects of each of the criticality levels. di 2. Based on the set D the set DN  { dni | i  1..4 } of ratio dni  is formed, where n – the total n number of software defects detected during the basic testing. 3. All the rules of forming the conclusion about establishing the presence of residual defects are analyzed, and based on known facts (elements d 3 and d 4 of the set D; elements dn1 and dn 2 of the set DN) conclusions are sought, which follow from these facts. The analysis of the rules of forming the conclusion is as follows. In the above set of rules the search for a rule for elements d 3 and d 4 of the set D and elements dn1 and dn 2 of the set DN is conducted. If the value of the elements satisfies the condition of the left part of the rule, then this rule, in fact, becomes one of (or the only) conclusions of the method. If none of the rules worked, then a conclusion is made about establishing the absence of residual defects. Based on the developed rules and method the structure of system of developing the defect-free medical software by establishing the presence of residual defects is developed (Figure 3). Figure 3: Structure of the system of developing the defect-free medical software by establishing the presence of residual defects System of developing the defect-free medical software by establishing the presence of residual defects functions as follows. The user of the system submits a report on basic testing of the medical software. Block of semantic parsing of the report and preparation of data for ANN performs semantic parsing of the report, selecting from it information about software defects found during the basic testing, and then converts this information from the linguistic form of presentation to quantitative form using data tables of the knowledge base. Knowledge base contains tables for assigning numbers to the types of detected software defects. ANN processes all obtained quantitative information about software defects detected during the basic testing, and then provides information about the levels of criticality of detected defects (0 or 1 for each of the 4 levels, where 1 means that the defect belongs to this level of criticality). The results of ANN are recorded in the data table of the knowledge base. The knowledge base also contains the above rules for forming the conclusion about establishing the presence of residual defects. Further, according to the above method of developing the defect-free software by establishing the presence of residual defects, a conclusion about establishing the presence or absence of residual defects is formed (indicating the criticality level(s) of residual defects in case of their presence) and issued to the user of the system. Therefore, the proposed system of developing the defect-free medical software by establishing the presence of residual defects allows the user, based on the report on the results of the basic testing, to obtain a conclusion about establishing the presence or absence of residual defects (indicating the criticality level(s) of residual defects in case of their presence). Since the clarification of the distribution of the type of software defects to form a conclusion about the presence of residual software defects was carried out in this study, the threshold values of the number of defects of each criticality level, exceeding which the conclusion is made about the presence of the residual defects (indicating the criticality level(s) of residual defects in the case of establishing their presence), are not described in known literature references. For the establishment of these thresholds, a study of the number of the medical software defects was conducted, which was developed by software companies in Khmelnytskyi and consisted of a different number of lines of code, taking into account and without taking into account the impact of defects of one criticality level on the occurrence of the defects of the next criticality level. The results of this study are shown in Table 1. Table 1 The number of the medical software defects, taking into account and without taking into account the impact of defects of one criticality level on the occurrence of defects of the next criticality level The number of detected The actual number of defects without taking defects into account the impact of defects of one criticality level on the occurrence of defects of the next criticality level Number of lines of code 100 1000 10000 100 1000 10000 The total number of defects 10 25 68 16 36 85 Minor defects 8 19 51 8 19 51 Moderate defects 2 5 16 5 14 33 Serious defects 0 1 1 2 2 1 Catastrophic defects 0 0 0 1 1 0 As a result of the analysis of Table 1, the following conclusions can be drawn: 1. For the medical software source code from 100 operators, the number of minor defects is 80% (more than 75%) of the total number of detected defects without taking into account the interaction of defects of one criticality level on the occurrence of defects of the next criticality level, and because of this there 3 moderate defects appearanced; the number of moderate defects is 50% of the total number of detected defects without taking into account the interaction of defects of one criticality level on the occurrence of defects of the next criticality level, and because of this there 2 serious defects appearanced that caused 1 catastrophic defect; 2. For the medical software source code from 1000 operators, the number of minor defects is 76% (more than 75%) of the total number of detected defects without taking into account the interaction of defects of one criticality level on the occurrence of defects of the next criticality level, and because of this there 9 moderate defects appearanced; the number of moderate defects is 56% (more than 50%) of the total number of detected defects without taking into account the interaction of defects of one criticality level on the occurrence of defects of the next criticality level, and because of this there 1 serious defects, 2 serious defects appearanced, that caused 1 catastrophic defect; 3. For the medical software source code from 10000 operators, the number of minor defects is 75% of the total number of detected defects without taking into account the interaction of defects of one criticality level on the occurrence of defects of the next criticality level, and because of this there 17 moderate defects appearanced; the number of moderate defects is 49% (not more than 50%) of the total number of detected defects without taking into account the interaction of defects of one criticality level on the occurrence of defects of the next criticality level, therefore, serious defects due to the accumulation of moderate defects did not occur; the same serious defect did not cause a catastrophic defect. In this case, the threshold values of the number of defects of each criticality level, in excess of which the conclusion is made about the presence or absence of residual defects (indicating the criticality level(s) of residual defects in case of their presence), are entered on the basis of heuristic estimates (Table 1) as follows: 1. If the ratio dn1 of the total value of defects of the 1st level of criticality (minor defects) to the total number of defects detected during the basic testing is equal to or exceeds 75%, it is concluded about establishing the presence of residual defects of the 2nd criticality level (moderate defects). 2. If the ratio dn 2 of the total value of defects of the 2nd level of criticality (moderate defects) to the total number of defects detected during the basic testing is equal to or exceeds 50%, it is concluded about establishing the presence of residual defects of the 3rd criticality level (serious defects). 3. If the total value d 3 of defects of the 3rd criticality level (serious defects) exceeds 2, the conclusion is made about establishing the presence of residual defects of the 4th criticality level (catastrophic defects). 4. If the total value d 4 of defects of the 4th criticality level (catastrophic defects) is equal to or exceeds 1, then a conclusion is made about the unsuitability of the software and the possible failure of the system. So, elements of the set R (thresholds) have the following values: r1  0.75 ; r2  0.5 ; r3  2 ; r4  1 . The analysis of Table 1 shows that in excess of such values there are residual defects of higher criticality levels, so these values are used as thresholds in forming a conclusion about establishing the presence or absence of residual defects (indicating the level(s) of critical residual defects in case of establishment of their presence). 4. Results & discussion Several experiments were conducted with the proposed system of developing the defect-free medical software by establishing the presence of residual defects. During the first experiment, the user of the system submitted a report on basic testing of the software module for automation of medical processes of the family medicine outpatient clinic of Ozerna microdistrict (Khmelnytskyi). Block of semantic parsing of the report and preparation of data for ANN performed semantic parsing of the report, selecting from it information about software defects found during the basic testing, and then converted this information from a linguistic form of presentation to a quantitative form using data tables of the knowledge base. ANN processed information about software defects detected during the basic testing, and then provided the following information: {[0;0;1;0] [1;0;0;0] [1;0;0;0] [0;1;0;0] [0;1;0;0] [0;1;0;0] [1;0;0;0] [1;0;0;0]} After deciphering these data, it becomes clear that one defect of the 3rd level of criticality (serious), three defects of the 2nd level of criticality (moderate) and four defects of the 1st level of criticality (minor) were diagnosed. Further, according to the developed method of developing the defect-free software by establishing the presence of residual defects, sets D1  { 4;3;1;0 } and DN1  { 0.5;0.375;0.125;0 } are formed. All the rules of forming a conclusion about establishing the presence of residual defects are analyzed, and conclusions are found on the known facts, which of these facts follow: dn1  r1 , i.e. rule 1 does not work; dn2  r2 , i.e. rule 2 does not work; d 3  r3 , i.e. rule 3 does not work; d 4  r4 , i.e. rule 4 does not work too. Therefore, none of the rules worked, so the conclusion is made about establishing the absence of residual defects for the 1st experiment. During the second experiment, the user of the system submitted a report on basic testing of the software module "Medical card of an outpatient" of the family medicine outpatient clinic of Ozerna microdistrict (Khmelnytskyi). Block of semantic parsing of the report and preparation of data for ANN performed semantic parsing of the report, selecting from it information about software defects found during the basic testing, and then converted this information from a linguistic form of presentation to a quantitative form using data tables of the knowledge base. ANN processed information about software defects detected during the basic testing, and then provided the following information: {[0;0;1;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [0;0;1;0] [1;0;0;0] [0;0;0;1] [0;1;0;0] [0;1;0;0] [0;1;0;0] [1;0;0;0] [0;0;0;1] [0;0;1;0] [1;0;0;0] [1;0;0;0] [0;0;0;1] [1;0;0;0] [0;1;0;0] [0;1;0;0] [0;0;0;1]} After deciphering these data, it becomes clear that four defects of the 4th level of criticality (catastrophic), three defects of the 3rd level of criticality (serious), five defects of the 2nd level of criticality (moderate) and eight defects of the 1st criticality level (minor) have been diagnosed. Further, according to the developed method of developing the defect-free software by establishing the presence of residual defects, sets D2  { 8;5;3;4 } and DN 2  { 0.4;0.25;0.15;0.2 } are formed. All the rules of forming a conclusion about establishing the presence of residual defects are analyzed, and conclusions are found on the known facts, which of these facts follow: dn1  r1 , i.e. rule 1 does not work; dn2  r2 , i.e. rule 2 does not work; d 3  r3 , i.e. rule 3 works; d 4  r4 , i.e. rule 4 works too. Thus, the developed system forms a conclusion about establishing the presence of residual defects of the 4th level of criticality (catastrophic defects) and about the unsuitability of the software and the possible failure of the software module. During the third experiment, the user of the system submitted a report on basic testing of the software module "Laboratory" of the family medicine outpatient clinic of Ozerna microdistrict (Khmelnytskyi). Block of semantic parsing of the report and preparation of data for ANN performed semantic parsing of the report, selecting from it information about software defects found during the basic testing, and then converted this information from a linguistic form of presentation to a quantitative form using data tables of the knowledge base. ANN processed information about software defects detected during the basic testing, and then provided the following information: {[1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [0;0;1;0] [1;0;0;0] [1;0;0;0] [0;1;0;0] [0;1;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [0;1;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [1;0;0;0] [0;1;0;0] [0;1;0;0] [1;0;0;0]} After deciphering this data, it becomes clear that one defect of the 3rd level of criticality (serious), five defects of the 2nd level of criticality (moderate) and twenty-four defects of the 1st level of criticality (minor) have been diagnosed. Further, according to the developed method of developing the defect-free software by establishing the presence of residual defects, sets D3  { 24;5;1;0 } and DN 3  { 0.8;0.17;0.03;0 } are formed. All the rules of forming a conclusion about establishing the presence of residual defects are analyzed, and conclusions are found on the known facts, which of these facts follow: dn1  r1 , i.e. rule 1 works; dn 2  r2 , i.e. rule 2 does not work; d 3  r3 , i.e. rule 3 does not work; d 4  r4 , i.e. rule 4 does not work too. Thus, the developed system forms a conclusion about establishing the presence of residual defects of the 2nd level of criticality (moderate). During the fourth experiment, the user of the system submitted report on basic testing of the software module "Accounting of the functional diagnostics room" of the family medicine outpatient clinic of Ozerna microdistrict (Khmelnytskyi). Block of semantic parsing of the report and preparation of data for ANN performed semantic parsing of the report, selecting from it information about software defects found during the basic testing, and then converted this information from a linguistic form of presentation to a quantitative form using data tables of the knowledge base. ANN processed information about software defects detected during the basic testing, and then provided the following information: {[0;1;0;0] [1;0;0;0] [0;1;0;0] [0;1;0;0] [0;1;0;0] [1;0;0;0] [0;1;0;0] [0;1;0;0] [1;0;0;0] [1;0;0;0] [0;1;0;0] [1;0;0;0] [1;0;0;0] [0;1;0;0] [0;1;0;0]} After deciphering this data, it becomes clear that nine defects of the 2nd level of criticality (moderate) and six defects of the 1st level of criticality (minor) have been diagnosed. Further, according to the developed method of developing the defect-free software by establishing the presence of residual defects, sets D4  { 6;9;0;0 } and DN 4  { 0.4;0.6;0;0 } are formed. All the rules of forming a conclusion about establishing the presence of residual defects are analyzed, and conclusions are found on the known facts, which of these facts follow: dn1  r1 , i.e. rule 1 does not work; dn2  r2 , i.e. rule 2 works; d 3  r3 , i.e. rule 3 does not work; d 4  r4 , i.e. rule 4 does not work too. Thus, the developed system forms a conclusion about establishing the presence of residual defects of the 3rd level of criticality (serious). During the fifh experiment, the user of the system submitted report on basic testing of the software module "Accounting of the office of radiological, fluorographic studies and magnetic resonance imaging" of the family medicine clinic of Ozerna district (Khmelnytskyi). Block of semantic parsing of the report and preparation of data for ANN performed semantic parsing of the report, selecting from it information about software defects found during the basic testing, and then converted this information from a linguistic form of presentation to a quantitative form using data tables of the knowledge base. ANN processed information about software defects detected during the basic testing, and then provided the following information: {[1;0;0;0] [1;0;0;0] [1;0;0;0] [0;1;0;0] [0;1;0;0] [0;1;0;0] [1;0;0;0] [1;0;0;0] [0;1;0;0] [0;1;0;0]} After deciphering these data, it becomes clear that five defects of the 2nd level of criticality (moderate) and five defects of the 1st level of criticality (minor) were diagnosed. Further, according to the developed method of developing the defect-free software by establishing the presence of residual defects, sets D5  { 5;5;0;0 } and DN 5  { 0.5;0.5;0;0 } are formed. All the rules of forming a conclusion about establishing the presence of residual defects are analyzed, and conclusions are found on the known facts, which of these facts follow: dn1  r1 , i.e. rule 1 does not work; dn2  r2 , i.e. rule 2 works; d 3  r3 , i.e. rule 3 does not work; d 4  r4 , i.e. rule 4 does not work too. Thus, the developed system forms a conclusion about establishing the presence of residual defects of the 3rd level of criticality (serious). During the sixth experiment, the user of the system submitted report on basic testing of the software module "Accounting for the endoscopic office" of the family medicine outpatient clinic in the Ozerna district (Khmelnytskyi). Block of semantic parsing of the report and preparation of data for ANN performed semantic parsing of the report, selecting from it information about software defects found during the basic testing, and then converted this information from a linguistic form of presentation to a quantitative form using data tables of the knowledge base. ANN processed information about software defects detected during the basic testing, and then provided the following information: {[0;0;1;0] [0;0;1;0] [0;0;1;0] [0;0;0;1] [0;0;0;1]} After deciphering these data, it becomes clear that three defects of the 3r level of criticality (serious) and two defects of the 4th level of criticality (catastrophic) were diagnosed. Further, according to the developed method of developing the defect-free software by establishing the presence of residual defects, sets D6  { 0;0;3;2 } and DN 6  { 0;0;0.6;0.4 } are formed. All the rules of forming a conclusion about establishing the presence of residual defects are analyzed, and conclusions are found on the known facts, which of these facts follow: dn1  r1 , i.e. rule 1 does not work; dn2  r2 , i.e. rule 2 does not work; d3  r3 , i.e. rule 3 works; d 4  r4 , i.e. rule 4 works too. Thus, the developed system forms a conclusion about establishing the presence of residual defects of the 4th level of criticality (catastrophic defects) and about the unsuitability of the software and the possible failure of the software module. The results of all 6 experiments will be presented in the form of a diagram of the detected medical software defects of different levels of criticality – Figure 4. Thus, as shown by the conducted experiments, the proposed system of developing the defect-free medical software by establishing the presence of residual defects as a result of its operation issues a conclusion about establishing the presence or absence of residual defects (indicating the level(s) of critical residual defects in case of their presence) based on the processing of information on the number and types of defects detected during the basic testing, which is contained in the report of the basic testing. 30 Minor software defects 25 20 Moderate software 15 defects 10 Serious software defects 5 0 Catastrophic software defects Total software defects Figure 4: Diagram of detected software defects of different levels of criticality as a result of 4 experiments Therefore, the proposed system allows developing the defect-free medical software by detecting the residual defects in the software after the basic testing, thereby increasing the reliability of testing and, accordingly, increasing the quality of the medical software. 5. Conclusions On the one hand, the annual increase in the number of lines of software source code, and on the other – the increase in the number of news about software defects, give the right to rightly affirm a potential increase in the number of residual software defects. The paper develops the method of developing the defect-free medical software by establishing the presence of residual defects, the essence of which is to identify the set of defects of different levels of criticality and analysis of this set for the presence or absence of residual defects. The method differs from the known ones in that the input information about the results of the main testing is processed by an ANN. The structure of the system of developing the defect-free medical software by establishing the presence of residual defects is proposed, which allows the user on the basis of the report on the results of the basic testing to get a conclusion about establishing the presence or absence of residual defects (indicating the level(s) of critical residual defects in case of their presence). In general, the proposed system allows the development of defect-free medical software by detecting residual defects in software after the basic testing, thereby increasing the reliability of testing and, accordingly, increasing the quality of the medical software. 6. References [1] S. McConnell, Code complete, Microsoft Press, Redmond, 2013. [2] T. Hovorushchenko, Methodology of evaluating the sufficiency of information for software quality assessment according to ISO 25010. Journal of Information and Organizational Sciences 42 1 (2018) 63-85. doi: 10.31341/jios.42.1.4. [3] T. Hovorushchenko, O. Pavlova, M. Bodnar, Development of an intelligent agent for analysis of nonfunctional characteristics in specifications of software requirements. Eastern-European Journal of Enterprise Technologies 1 2 (2019) 6-17. doi: 10.15587/1729-4061.2019.154074. [4] T. Hovorushchenko, O. Pavlova, Evaluating the software requirements specifications using ontology-based intelligent agent, in: Proceedings of 2018 IEEE International Scientific and Technical Conference “Computer Science and Information Technologies”, СSIT’2018, Lviv, 2018, vol.1, pp.215-218. doi: 10.1109/STC-CSIT.2018.8526730. [5] T. Hovorushchenko, O. Pomorova, Evaluation of Mutual Influences of Software Quality Characteristics Based ISO 25010:2011, in: Proceedings of 2016 International Scientific and Technical Conference “Computer Science and Information Technologies”, CSІТ’2016, Lviv, 2016, pp. 80-83. doi: 10.1109/STC-CSIT.2016.7589874. [6] T. Hovorushchenko, O. Pomorova, Information Technology of Evaluating the Sufficiency of Information on Quality in the Software Requirements Specifications. CEUR-WS 2104 (2018) 555-570. [7] I. Margarido, J. Faria, R. Vidal, M. Vieira, Classification of Defect Types in Requirements Specifications: Literature Review, Proposal and Assessment, in: Proceedings of 2011 Iberian Conference on Information Systems and Technologies, CISTI’2011, Chaves, 2011, pp. 1-6. [8] M. Felderer, A. Beer, Using Defect Taxonomies for Testing Requirements. IEEE Software 32 (2015) 94-101. doi: 10.1109/MS.2014.56. [9] K. Gopal, S. Jadoo, J. Ramgoolam, V. Devi, Software Quality Problems in Requirement Engineering and Proposed Solutions for an Organization in Mauritius. International Journal of Computer Applications 137 (2016) pp. 23-31. doi: 10.5120/ijca2016908698 [10] B. Marjerison, The Software Bug Book: Thoughts on Software Quality, Scotts Valley, Scotland, 2013. [11] K. Naik, P. Tripathy, Software Testing and Quality Assurance: Theory and Practice, Wiley Publishing, New York, 2011. [12] G. Blokdyk, Nintendo Software Planning & Development: Second Edition, CreateSpace Independent Publishing Platform, New York, 2018. [13] S. Loveland, G. Miller, Jr. Prewitt, M. Shannon, Software Testing Techniques: Finding the Defects that Matter, Mandevilla Press, Florida, 2014. [14] J. Capers, Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies, McGraw-Hill Education, Orlando, 2010. [15] J. Huang, Software Error Detection through Testing and Analysis, Wiley Publishing, New York, 2009. [16] A. Drozd, M. Drozd, V. Antonyuk, Features of Hidden Fault Detection in Pipeline Components of Safety-Related System. CEUR-WS 1356 (2015) 476–485. [17] O. Drozd, V. Antoniuk, V. Nikul, M. Drozd, Hidden faults in FPGA-built digital components of safety-related systems, in: Proceedings of the 14th International Conference “Modern problems of radio engineering, telecommunications and computer science”, TCSET’2018, Lviv-Slavsko, 2018, pp. 805-809. doi: 10.1109/TCSET.2018.8336320. [18] O. Drozd, I. Perebeinos, O. Martynyuk, K. Zashcholkin, O. Ivanova, M. Drozd, Hidden fault analysis of FPGA projects for critical applications, in: Proceedings of IEEE International Conference “Modern problems of radio engineering, telecommunications and computer science”, TCSET’2020, Lviv-Slavsko, 2020, paper 142. doi: 10.1109/TCSET49122.2020.235591. [19] O. Mishchuk, R. Tkachenko, I. Izonin, Missing data imputation through SGTM neural-like structure for environmental monitoring tasks. Advances in Intelligent Systems and Computing 938 (2019) 142-151. doi: 10.1007/978-3-030-16621-2_13 [20] How tech firm Shadow sought to revolutionize Democratic campaigns – but stumbled in Iowa, 2020. URL: https://www.washingtonpost.com/technology/2020/02/04/how-tech-firm-shadow- sought-revolutionize-democratic-campaigns-stumbled-iowa. [21] British Airways passengers stranded after IT failures, 2019. URL: https://www.bbc.com/news/uk-49261497. [22] Starliner anomaly to prevent ISS docking, 2019. URL: https://spacenews.com/starliner-anomaly- to-prevent-iss-docking. [23] The 2018 Software Fail Watch Awards, 2018. URL: https://www.tricentis.com/blog/software- fail-awards-2018. [24] Fiat Chrysler is recalling more than 1.25 million pickup trucks worldwide over a software error that "may be related" to a death and two injuries, 2017. URL: https://www.bbc.com/news/technology-39898319. [25] What is the cost of poor software quality in the U.S.?, 2021. URL: https://www.synopsys.com/blogs/software-security/poor-software-quality-costs-us. [26] Software Fails Watch, 5th edition, 2019. URL: https://www.tricentis.com/wp- content/uploads/2019/01/Software-Fails-Watch-5th-edition.pdf.