Cost Benefit Analysis of Incorporating Security and Evaluation of Its Effects on Various Phases of Agile Software Development

,


Introduction
e major hurdles in determining the cost of building safe software are a lack of accurate data, a lack of agreement on measuring methods, and a relatively new focus on safety. In addition, considerable quantification and software development cost assessments are being undertaken. Work began with the COCOMO (Constructive Cost Model) [1]. Security costs are directly commensurated with software quality. In general, improved software quality involves better design, aggressive testing, and validation, all of which have a direct impact on costs. e advantages of such transactions may, in addition, nevertheless exceed the expenses. e costs for greater quality are divided into "compliant" and "noncompliant." Compliance means the specified quality may be achieved. To attain the proper quality, either (1) remove the origin of defects (improved training, meetings on quality improvement, and design reviews) or (2) remove flaws through product evaluation and monitoring (code inspection, screening, and software calibration activities) e financial return assessment for improved quality is done on the basis of the data used by the company and shows that this ROI is promising and significant.
Sadly, any cost metric for software quality is a challenge because these activities are often brand, technology, or organization-specific and so impossible to identify. Rather, it has been proven that intelligent employees, the use of case tools, and the considerably more transparency in planning, design, and so on boost product quality [2,3]. Greater quality minimizes the frequency of bugs, but it does not influence the product size, does not affect the product's complexity, and so on. Improving the product nevertheless can entail more or less product complexity, more or less size, and more or less product flexibility. erefore, the design of the product can incur indirect costs that exceed the cost of compliance, such as the costs of case tools [4].
To comprehend the benefits of safe software, we focus on research that explains methodologies and frameworks to support customer information security decision-making, i.e., from the viewpoint of an IT-based organization that wishes to defend itself against cyber-assault. is research is relevant as long as secure software development is another option to invest in information safety [5,6].
We adapt this approach to the nature of software development and to evaluate investment returns for secure software development techniques. In general, the benefits are computed as the defined cash worth of losses saved by safe production methods of software. e principal discrepancies in the results are how the averted losses are measured. e data required to evaluate damage (including potentially safe software development strategies) with or without security expenses were based on operational data. Bypass rate calculation here is a crucial issue. Current security methods prohibit bypass rates from estimating the fraction of failure (for example, invasion of privacy, assault, virus infections, and internal theft) and thus not recorded in administrative data on detected intrusions or losses. To determine the average rate of that sort of loss event, the identified rate of a particular loss incident is multiplied by the inversion of the bypass rate. e amount of damage experienced by a company in relation to the loss case, computed in dollars, is measured by administrative statistics or other means (such as assessments by managers) independently [4]. e manner in which loss data are produced is another important difference.
is literature is based on the approach to the interpretation of the importance of the market by recognizing that the major advance of safe software development is that software users may have a greater risk avoidance compared with baseline [7]. erefore, the value of secure software includes parts equivalent to that of investment in the protection of information. e collection of the data will be tough. In general, although the developer is a member of an organization, it is unclear if the developer would be able to make an assessment of the frequency and related losses of failures in administrative records [8,9]. Developers too cannot estimate these amounts. In addition, developers will not be able to evaluate the proportion of the benefits they have generated. Vendors are likely to be more concerned about the loss of credibility and a loss of potential revenue.
Other prospective advantages are also available. It is also important because fewer software bugs will require fewer fixes and improvements in security. As a result, a second component of the benefit of safe software development is the decrease in patching expenses. e risk mechanism for this may be altered while there is no established technique for determining the averted patching cost. e gain should therefore be estimated as the difference between the basic patching cost and the anticipated patching cost [10]. e basic cost of patches is calculated by the reported number of vulnerabilities per thousand lines of code per year multiplied by the detection rate, multiplied by the average vulnerability cost of patches. e discovery rate is needed in this scenario because not all vulnerabilities in the system are likely to be identified.
Consequently, our suggested method is versatile, allowing users to quantify the value in other ways. However, we are careful to reduce the chance of duplication.

Calculating Security Benefits
Most companies are now going towards agile applications. e financial impact of Agile encourages other businesses to move to agile practices. CIOs today are also highly concerned about the financial analysis of Agile vs. Waterfall. e important elements that cause many IT companies to get rid of the traditional waterfall process are costs, benefits, ROI, NPV, and ROA [11]. Some statistics from a recognized study are presented below to highlight the advantages of agile software development over conventional software development [12,13].

Costs.
e project needs to be accomplished by an organization within the budget. As the recent product introduction becomes faster than ever, projects under budgetary limitations are increasingly vital.

Benefits.
e agile is more effective because there are fewer defects in the end output. As the quality of the product becomes good with several revisions, the product is tested for a number of times due to iterations that lead to greater product quality.

ROI.
Agile offers more benefits than the traditional strategy at a low cost. e higher profit-cost differential makes ROIs (return on capital) approximately seven times higher than the traditional solution possible.

NPV.
NPV is the difference between cash influx and cash outflow for a period of time. is is about 200% higher than traditional NPV.
2.5. ROA. It offers us an indication of the properties being used efficiently. e assets are only utilized for the project in the typical way. is reduces the idle period of the capital of a project. However, the items are utilized at the optimum level due to their adaptable character. e increase in idle time would put the project at risk. ROA will therefore also allow us to understand the hazards of any undertaking. Agile reduces the project load by almost 140% compared with conventional techniques. Figure 1 shows the security benefit analysis in terms of traditional and agile software development.
To estimate the advantages of using security for a software project [14], the following details must be collected: (1) Size of Software. It is the number of source code lines.
(2) Bug Rate. e number of bugs per thousand source code lines occurred in the software (tsloc) (both for security and nonsecurity bugs). (3) Costs for Errors. It is the average error cost. e bug costs are separated into the costs of prerelease and postrelease [15]. (4) Prerelease Component. It is the rate at which flaws are detected and addressed prior to release, or the average cost of bug fixing prior to software release. (5) Postrelease Component. It is the percentage of security bugs that attackers believe to discover and use [18].
(5a) Overheads for media relations, including manmonth and any additional costs. (5b) Legal fees, including man-month expenditures and any additional costs incurred. (5c) Man-month cost of customer service-the effect on future income lost because of security infringement [16]. Revenues are anticipated to return within one year. (6) Postsecurity Component. Bug detection in prerelease increases on average when protection and checks are enhanced. e advantage is measured by two alternative calculations as follows: (6a) e approximate decrease (by age) in the overall number of defects caused by enhanced security standards and procedures [17] is measured. One evaluates the projected losses prior to adding security, whereas the other calculates the anticipated expenditures after adding security.
e prerelease components can be computed as follows: Here, C [pr] defines the prerelease component; B [per d] represents the percentage of bugs discovered; and F [cpr] shows the fixed cost during prerelease.
Here, C [e] defines the exploit component; N [sb] represents the number of securities [18] with bugs; N [nsb] is the number of nonsecurity bugs; B [pd] is the percentage of bugs discovered; B [pe] represents the percentage of bugs exploited; and T [c] is the total cost and can be computed as follows: where T [prc] represents the total public relation cost; T [lc] shows the total legal cost; T [csc] shows the total client support cost; P [l] represents the profit lost; and C [o] shows the other costs as follows:

Mathematical Problems in Engineering
Here, S [pl] shows the percentage of sales lost; R [ts] represents the revenue from total sales; and P [m] depicts the profit margin. Component postrelease can be computed as follows: Here, C [por] shows the postrelease component; D [ppor] represents the percent discovered postrelease; and T [cpor] defines the total cost postrelease.
Here, T [dc] shows the total diagnostic cost; T [pc] represents the total patch cost; and T [tc] defines the total testing cost. Expected cost presecurity [19] can be computed as follows: Here Here, C [pr] shows the prerelease constituent; B [pd] defines the percentage of bugs discovered prerelease; B [ipd] shows the percentage of increase in bug prereleases; and C [prf] shows the prerelease fix cost. Exploit constituents can be computed as follows: shows the size of project and N [loc] represents the number of lines of code. Figure 2 shows the value of various cost drivers with reference to security incorporated prerelease or postrelease. It distinguishes between the security prerelease and security postrelease.

Calculation of Security Costs
To estimate the cost of secure development, we modify the current models to include security aspects. Recent work in the development of secure software tries to embed security features in proven cost estimating models [20,21] (particularly COCOMO-II). e main idea behind this method is that enhancing safety is likely to increase the effort necessary to make the product. Most conceptually, as E α −E � E β, where E signifies the amount of effort in the person month and ΔE, supplementary effort is needed to create a secure item, E α is the effort required with security, and E β is the effort required without security. E α is evaluated with a certain certainty even though COCOMO-II is widely used in computing E β and customers are accustomed to these models. e effort level E formula (in person months) is provided as E (estimated) � aKLOCSF x Π (EM), where KLOC denotes the number of 1000 code lines and SF denotes the scaling factor. SF � 1.01 + 0.01 SUM (WI), where 5 scaling factors are used for WI. EM is a multiplier of effort. Every WI and EM is classified at a very low, nominal, moderate, and very high level. e sensitivity of each factor is calculated and tends to develop on the basis of the particular project setup.

Major Items of Cost.
(i) Using innovative CASE tools for the development of secure applications. (ii) User Training. Security requirements [22] will allow the company to provide the developers with more training. e cost will increase because of the following: (iii) Raising the amount of effort due to added safety, thereby increasing the cost. (iv) e impact of product delivery delay is due to increased surveillance.
More work could lead to a project delay; the details required from the right project personnel are as follows: (a) e percentage difference is determined in code size by adding encryption [23,24]. Team members, for example, will expect that improved security protocols would increase the size of the device by 5% in terms of the number of lines of code.
(b) e approximation of the software project's complexity (from very low to very high) before and after encryption is implemented. For example, a team member may believe that the complexity of the software project was low prior to the implementation of security protocols but then increased to moderate or extreme.
(c) e necessary amount of program documents before and after security measures is predicted.
(d) System analyst ability is approximated prior to and after safety implementation. (e) An expected ability of the programming team before and after security is implemented.
(f ) A rough estimate of experience on the tools needed to add protection to projects. (g) e anticipated change in production time prior to and following the implementation of safety measures is estimated.
(h) An approximation of the overall commitment (in men's months) is mandatory to construct the software prior to implementing protection. (i) e total expense per worker per month is predicted, which is the amount charged for 30 days of working time on average. (j) e reliability parameters prior to and after protection are assessed. Customer-required training costs are estimated. e parameters considered for calculating training costs are total on-job employees, time spent on training by an individual employee, and per day, the cost of training.
An estimate of the losses incurred as a result of delayed business entry is depicted by the following equation: Here, E [c] shows the effort change; C [psi] defines the percentage code size increase; C [b] shows the complexity before; C [a] represents the complexity; D [b] shows the documentation before; D [a] defines the documentation; AC [b] represents the analyst capability before; AC [a] defines the analyst capability; PC [b] shows the programmer capability before; PC [a] represents the programmer capability; TO [b] defines the tools before; TO [a] represents the tools; T [b] defines the time before; T [a] represents the time; R [b] defines the reliability before; and R [a] shows the reliability. e numerator and denominator for each of the words in the "Effort-Change" equation are taken from the developer's responses to the respective standards above and assigned a numeric value accordingly. We have selected COCOMO because it is well established and nonproprietary [25]. Figure 3 depicts the approximate complexity of the project before and after the security is integrated. It distinguishes between the complexity of presecurity and the complexity of the project postsecurity cost scale. Figure 4 shows the estimation of the expected shift in development time before and after the introduction of security processes. It distinguishes between the development time presecurity and development time postsecurity. Figure 5 shows the approximation of the amount of documentation needed beforehand and afterward the integration of security. It distinguishes between the documentation required presecurity and documentation required postsecurity. Figure 6 depicts the approximate system analyst capability when presecurity and postsecurity are implemented. It compares between the analyst capability presecurity and analyst capability postsecurity values. Figure 7 shows the approximate programmer capability when presecurity and postsecurity are implemented. It compares between the programmer capability presecurity and programmer capability postsecurity cost scales. Figure 8 depicts an estimate of the resources needed to add security to the given project. e experience of team members with these resources presecurity and postsecurity deployment was taken into consideration. Figure 9 shows an estimation of the reliability specifications presecurity and postsecurity incorporation. Figure 10 demonstrates the corresponding value of each cost driver for each option (very low to very high) whichever is appropriate. e cost scale is very high, high, moderate,        low, and very low, whereas the cost drivers are COP (complexity of project), DT (development time), DR (documentation required), AC (analyst capability), PC (programmer capability), TR (tools required), and RR (required reliability). Figure 11 shows the correlation between cost and various components affecting it, like the number of bugs which will increase in case of security incorporated prerelease because of improved protection and control; subsequently, the size of the project, the effort required, and development time will be more as security is incorporated prerelease, thereby increasing the overall cost. e maintenance of the project will be less in case the security incorporated [26] prerelease, thereby the maintenance cost will be less compared with postrelease incorporation of security.
e planning and quality of the final product will be better in case of prerelease incorporation of security. Opportunity costs can be computed as follows: Here, C [o] represents the opportunity cost; E [it] defines the number of employees in training; T [l] Is the average length of training; and C [atc] is the average training cost. e cost of tools can be computed as follows: Here, C [to] defines the cost of case tools/hardware or software; E [c] shows the capital expenses for purchasing hardware or software for a project. e total cost can be computed as follows: Here, C [t] , C [e] , C [tr] , C [o] , C [to] , and C [d] represent the total cost, cost of effort, cost of training, cost of opportunity, cost of tools, and cost of delay to market. Figure 12 shows that risk analysis is the best security activity, coding rule is the worst, and threat modeling is the average security activity to be incorporated during the planning phase. Figure 13 shows that coding rule is the best security activity, role matrix is the worst, and vulnerability testing is the average security activity to be incorporated during the coding phase. Figure 14 shows that security testing is the best security activity, operational planning is the worst, and identifying trust boundaries is the average security activity to be incorporated during the testing phase. Figure 15 shows the best, worst, and average security activities during the planning, coding, and testing phases of software development.      Figure 12: Best, worst, and average security activities in the planning phase.  Figure 13: Best, worst, and average security activity in the coding phase.   Figure 14: Best, worst, and average security activity in the testing phase.

Conclusion
e cost and benefit of each project will differ. Furthermore, cost and benefit can be divided into two categories: tangible and intangible cost and benefit. Hardware prices, professional wages, and software expenditures are all examples of tangible costs. ey are measured and evaluated. Examples of tangible costs include the acquisition of hardware or software, employee training, and staff compensation. Intangible costs are those that cannot be quantified. e expense of a malfunction of an online system during banking hours will result in the bank losing money. Benefits are also tangible or intangible. For example, more customer satisfaction, improved company status, and so on are all intangible benefits whereas improved response time and producing error free output such as producing reports are all tangible benefits. Both tangible and intangible costs and benefits should be considered in the evaluation process.
is article describes the economic advantage of adding security during several agile software processes. e examination of the cost benefits is divided in two parts: the prerelease portion and the postrelease section. e general bug identification rate is increasing in prerelease due to improved security and control. Two distinct methods are used to calculate the benefit. e total number of bugs was projected to reduce due to the higher safety standards and controls. First, the estimated losses are computed before the security is added, and second the expected costs are calculated after the security is added. We should presume that the benefits of security integration outweigh the risks. It has been discovered that addressing security concerns during the initial phase costs up to 100x times less than addressing flaws in the released software. e article also defines each person's role, from the top of management down the hierarchy, in promoting the model and establishing a sustainable application [27][28][29][30].
Data Availability e data that support the findings of this study are available upon request to the corresponding author.

Conflicts of Interest
e authors declare that they have no conflicts of interest.  Figure 15: Best, worst, and average security activities during the planning, coding, and testing phases of software development.
Mathematical Problems in Engineering 9