## 4 Application  
The study addresses the problem of prioritizing the most recurring errors in a company's software projects for the defense sector. Software testing is the name of the process performed to evaluate a software application's functionality to determine whether the developed software meets the specified requirements and to produce a quality product without or with minimal errors. Software testing is the process of executing a program or application for the purpose of finding software bugs. Software testing aims not only to find bugs in existing software but also to use it efficiently and correctly and to find features that will improve its usability. Software testing is conducted manually as well as with ready-made automation tools. Whether the test is performed automatically or manually, the decision is made according to the software product's features and verification criteria. Manual tests can take longer because they require more workforce than automation. Although software testing often seems like a waste of time, it reduces costs in the long run by enabling early detection and prevention of errors. Errors and improvements resulting from each test are recorded with the help of tools such as Redmine and Jira, which are widely used in the software industry [79]. Through these tools, situations such as how many times the same error occurs, which versions it occurs in, the duration of the test, the closing date of the error, or whether the error caused another error can be tracked [79]. One of the disadvantages of the classical FMEA method, which is preferred for prioritizing errors, is that it evaluates the severity component similarly for all errors and does not consider different severity types. Therefore, in this study, a new risk-assessment model is proposed in which the severity component, which is one of the components of the classical FMEA method, is divided into five sub-severity components: severity on time, severity on quality, severity on cost, severity on solvability, and severity on usability when evaluating possible project software errors. Some risks have more effect on the quality of the project, while some risks have less effect on the quality of the project but more effects on the time of the project. Or, let us think of two risks, where the measure of their effects on the time of the project is the same amount or less. It may not be a very correct approach to accept the severity values as the same by accepting that the effects of the risks are only on time, because the severity of the risks on quality, cost, solvability, and usability may be different. For example, let us consider the errors E\({}_{47}\) and E\({}_{48}\) discussed in this study. If only the effect on the time of the project was taken into account when calculating the effect, the severity values of the two errors would be considered the same. However, for E\({}_{47}\), the severity on time is 1, the severity on quality is 7, the severity on cost is 5, the severity on solvability is 5, and the severity on usability is 5, and for E\({}_{48}\), the severity on time is 1, the severity on quality is 3, the severity on cost is 1, the severity on solvability is 2, and the severity on usability is 1. Therefore, the severity values of these two risks should not be accepted as the same. Unlike the classical FMEA method, which assumes the effects of these risks to be equal, the weighted FMEA model allows the risk effects to be analyzed in more detail and more precise results to be obtained. The proposed new model aims to avoid the disadvantage of classical risk-assessment methodologies in evaluating the effects of all risks similarly. In addition, since the weights of the sub-severity components used in the proposed model cannot be the same in the evaluated software projects, the sub-severity components were weighted with the fuzzy SWARA method, one of the MCDM techniques, together with the experts in the project team.