At present, despite the rapid development of the software engineering industry, a significant number of software projects remain that cannot be considered completely successful. The success of the software project means the timely implementation of the program project within the allocated budget and with the implementation of all necessary capabilities and functions [1][2][3][4][5].
Statistics on the success of software projects for 1994-2019, presented by The Standish Group International (CHAOS report) [1][2][3][4][5], gave the opportunity to see an increase in the number of successful projects and a decline in the number of failed projects in 2010-2019, while the share of problem projects is fairly stable in 2006-2019 and accounts for about 50% of projects.
Statistics [1][2][3][4][5] also show that only 16% of software projects are successfully completed by medium-sized companies on time and budget. The situation with large companies is much worse -only 9% of projects are invested on time and budget. Projects implemented by the largest American companies have about 42% of the functionality offered in the initial stages. Smaller companies do better: 78.4% of projects implement 74.2% of their planned functionality.
Research by McKinsey & Company [6] in collaboration with the University of Oxford also found that half of large-scale software projects with a total budget of more than $ 15 million significantly exceeded planned costs, including: average project overruns are 66%, average project time overruns are 33%, and the average number of profit losses is 17%.
Thus, software development is not always successful and is often associated with the risks of insufficient software functionality, non-compliance with project deadlines or budget overruns [7][8][9][10][11]. Risks are negative events of a probabilistic nature that negatively affect the outcome of the project; negative events and their magnitudes that reflect losses and damages from processes or products caused by defects in the design of requirements, by shortcomings in the justification of software projects, as well as in the subsequent stages of development, implementation and all software lifecycle [12][13][14]. Risks are manifested as possible negative consequences or losses during the operation of the software, as negative consequences of the operation or violation of the security of the software as a result of deviation of the characteristics of objects or processes from the specified customer requirements, which can cause the damage to the system, the external environment or the user (for example, loss of the system, loss of consequences of the person or team activity, personal damage or the emergence of legal liability for negative project results) [15,16].
Risk is a probable event that may or may not occur. The causes of occurrence and manifestation of risks can be: malicious, active influences of stakeholders or accidental negative manifestations of defects of the environment, system, actions of developers or users [17][18][19].
The risks of the accidental negative effects of defects in the absence of malicious effects on the system depend on failure situations that affect the workability and security of their basic functions realization, which can be caused by defects and anomalies in hardware, software, data or computational processes [17][18][19]. This significantly distorts the process of functioning of the systems, which can cause significant damage when using systems. The main sources of failure situations are incorrect initial design requirements, hardware failures and faults, defects or errors in software and data. Currently, there are no methods, which provide to guarantee the absence of defects either in the specifications, or directly in the programs, or in the operating documentation. From the end user's point of view, the manifestations of software defects can range from temporary inconveniences to man-made disasters. In real complex systems, catastrophic consequences and failures with large losses are possible, which may exceed the consequences of malicious influences, so such risks require adequate methods and means to minimize them [20,21].
In general, the following typical important reasons can be identified, which lead to the emergence of risk situations of the second type in the software projects: unrealistic assessment of the required time of project implementation and the allocated budget; unrealistic assessment of the capabilities of the development team; insufficient number and qualification of the development team; insufficient ability to use the tools by developers; errors in determining the requirements for the developed software (including insufficient detailing of requirements); violation of the basic rules of development processes (for example, violations in version control, which lead to the loss of versions); continuous change of requirements to the developed software during the project; a significant change in the market situation, which makes it meaningless to follow the original plans (for example, the emergence of affordable software on the market, which exceeds the capabilities of the developed software); continuous change of "rules of the game" in the development team or project group (rules of communication, division of responsibilities, segregation of duties); software architecture design errors; software development errors; integration errors; shortcomings of external service; technical and software failures [22][23][24].
There are three classes of risks in the software lifecycle:
• deficiencies and defects of functional suitability -distortion or incomplete implementation of the desired purpose, functions or interaction of software with the components of the system or the environment • insufficient and non-compliant with the requirements the implementation of the design characteristics of the quality of the software during its operation and use for its intended purpose • violation of restrictions on the use of economic, time or technical resources in the creation and use of software [25].
The task of developers is to reduce and eliminate risks. Reducing the risks of a software project helps to increase its success, quality, efficiency and effectiveness. Therefore, the actual task now is improving the risks management in software development.
For the successful implementation of software projects, one of the foundations of project management is risks management, which covers the entire software life cycle. Risks management is the process of making and implementing management decisions aimed at reducing the likelihood of an adverse outcome and minimizing possible losses caused by its implementation; these are systematic processes related to the identification, analysis and decision-making, which ensure the minimization of the negative consequences of the occurrence of risks events, as well as maximizing the probability and consequences of the occurrence of positive events [26,27]. Risks management includes a full understanding of the internal and external causes that affect the project and may lead to its failure. Risks analysis is performed after the formation of the project plan. The main purpose of risks management is the identification and control of factors that are rare and lead to project variations.
There are various models of risks management [26,27], the most used of which is the model of the Software Engineering Institute (SEI), which includes both the requirements of standards and known "best practices" of risks management. The SEI model is presented in the form of textual recommendations and a plan; there is no formalized method of risk management, which leads to the free use and interpretation of this model.
From the results of the analysis of the current state of the software development industry it follows that a promising area of research is the development of a mathematical method of risks management in software development. Therefore, the main task of this study is detailing and formalizing the method of the software risks management.
The method of the software risks management consists of the following stages:
Stage 1. Risks identification:
• Identification of possible sources of risks -let's present the 18 most common sources of risks in the form of the following set: PSR = {psr1, ..., psr18}, where psri -possible source of risk (i = 1..18), namely: psr1 -functional characteristics, psr2 -quality characteristics, psr3 -reliability characteristics, psr4 -applicability, psr5 -time performance, psr6maintainability, psr7 -reuse of components; psr8 -limitation of the total budget, psr9unavailable project cost, psr10 -low degree of realism in estimating project costs; psr11properties and possibilities of flexibility of change of plans, psr12 -possibilities of violation of the established terms of stages of a life cycle, psr13 -low degree of realism of plans and stages of a life cycle; psr14 -project strategy, psr15 -project planning, psr16project evaluation, psr17 -project documentation, psr18 -project forecasting; herewith psr1-psr7 belong to the sources of technical risks, psr8-psr10 belong to the sources of cost risks, psr11-psr13 belong to the sources of plan risks, psr14-psr18 belong to the sources of risks of project management processes and procedures.
The rules for determining the sources of risk are as follows:
if the software documentation has no functional characteristics or there are unrealistic or invaluable functional characteristics, then psr1 =1, else psr1 = 0; if the documentation does not contain quality characteristics or there are unrealistic or invaluable quality characteristics, then psr2 =1, else psr2 = 0; if there are no reliability characteristics in the documentation or there are unrealistic or invaluable reliability characteristics, then psr3 =1, else psr3 = 0; if the documentation does not contain recommendations for the future applicability of the software, then psr4 =1, else psr4 = 0; if the documentation lacks the characteristics of time performance or there are unrealistic or invaluable characteristics of time performance, then psr5 =1, else psr5 = 0; if the documentation does not contain recommendations for future software maintenance, then psr6 =1, else psr6 = 0; if there are no component reuse proposals in the documentation or there are unrealistic or invaluable component reuse proposals, then psr7 =1, else psr7 = 0; if there are restrictions on the total budget in the specification, then psr8 =1, else psr8 = 0; if the documentation indicates the unavailable cost of the project, then psr9 =1, else psr9 = 0; if the documentation has a low degree of realism in estimating the cost of the project, then psr10 =1, else psr10 = 0; if the documentation does not contain the properties and possibilities of flexibility to change plans or there are unrealistic or invaluable properties and possibilities of flexibility to change plans, then psr11 =1, else psr11 = 0; if in the documentation there are possibilities of violation of the established terms of stages of a life cycle, then psr12 =1, else psr12 = 0; if the documentation has a low degree of realism of plans and stages of the life cycle, then psr13 =1, else psr13 = 0; if there is no project strategy in the documentation or there is an unrealistic or invaluable project strategy, then psr14 =1, else psr14 = 0; if there is no project planning or there is unrealistic or invaluable project planning, then psr15 =1, else psr15 = 0; if there is no project evaluation or there is an unrealistic project evaluation, then psr16 =1, else psr16 = 0; if there is no project documentation, then psr17 =1, else psr17 = 0; if there is no forecast of project success or there is unrealistic or invaluable project forecasting, then psr18 =1, else psr18 = 0; if(𝑝𝑝𝑝𝑝𝑝𝑝 1 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 2 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 3 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 4 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 5 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 6 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 7 = 1), then there are technical risks; if (𝑝𝑝𝑝𝑝𝑝𝑝 8 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 9 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 10 = 1), then there are cost risks; if (𝑝𝑝𝑝𝑝𝑝𝑝 11 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 12 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 13 = 1), then there are plan risks; if (𝑝𝑝𝑝𝑝𝑝𝑝 14 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 15 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 16 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 71 = 1) ∪ (𝑝𝑝𝑝𝑝𝑝𝑝 18 = 1), then there are risks of project management processes and procedures.
• Identification of potential risks events -identification of all factors of anxiety and concern associated with the project, as well as constant consideration of other possible concerns, as the real problem at this stage is the risks that could not be identified. Based on the leading industry publications [10][11][12][13][14][15][16][17][18][19][20][21][22][23][24][25] let's form a set of potential risks events: PRE = {pre1, ..., pre43}, where prej -potential risk event (j = 1..43), namely: pre1 -delays in supply of equipment required for the software development process, pre2 -delays in the supply of software tools required to support the software development process, pre3 -reluctance of developers to use lifecycle support software tools, pre4 -rejection of CASE-tools, pre5requests for more powerful tools of software development, pre6 -insufficient performance of database(s), pre7 -reusable software components have defects and limited functionality, pre8 -inefficiency of software code generated by CASE tools, pre9inability to integrate CASE tools with other tools project support, pre10 -the rate of detection of defects in the system below the previously planned rate, pre11 -defective system components; pre12 -underestimation of project costs (excessively low cost), pre13 -overestimation of project costs (excessively high cost), pre14 -financial difficulties for the developer's company, pre15 -reduction of the project budget during its implementation, pre16 -high cost of reworks required due to changing requirements, pre17 -reorganization of the development company; pre18 -changes in the work schedule, pre19 -violation of the work schedule, pre20 -the need to change many requirements, pre21the need for a large number of repeated works, pre22 -underestimation of project time, pre23 -overestimation of project time, pre24 -software size exceeds the planned size, pre25 -the size of the software is much smaller than the planned size, pre26 -the appearance on the market of similar software before the release of the developed software, pre27 -the appearance on the market of more competitive software; pre28 -low morale of staff, pre29 -weak interaction between members of the development team, pre30 -passivity of the project manager, pre31 -insufficient competence of the project manager, pre32 -customer dissatisfaction, pre33 -insufficient number of professionals with the required professional level, pre34 -illness of a leading developer at the most critical time, pre35 -simultaneous illness of several developers, pre36 -inability to organize the necessary staff training, pre37 -change of priorities in project management, pre38 -underestimation of the required number of developers, pre39 -overestimation of the required number of developers, pre40excessive project documentation, pre41 -insufficient project documentation, pre42unrealistic forecasting of project results, pre43 -insufficient professional level of developers; herewith pre1-pre11 belong to potential technical risk events, pre12-pre17 belong to potential cost risk events, pre18-pre27 belong to potential plan risk events, pre28-pre43 belong to potential risk events of project management processes and procedures.
The rules for determining the risks for a particular software project are as follows:
if delays in supply of equipment required for the software development process are possible, then pre1 = «delays in supply of equipment required for the software development process», else pre1 = 0; if delays in the supply of software tools required to support the software development process are possible, then pre2 = «delays in the supply of software tools required to support the software development process», else pre2 = 0; … if project team includes developers with insufficient professional level, then pre43 = «insufficient professional level of developers», else pre43 = 0.
The rules for forming the set RSP ={rsp1,…,rspk} of risks of a particular software project are as follows:
• Determining the probability of risk (probability of occurrence of a risk event). For each risk from a set RSP, the development team must determine the probability of its occurrence in the range [0;1]. The set of probabilities of risks has the form: PR={pr1,…,prk}, where k is the number of risks of a particular software project.
The rules for classifying risks according to their probabilities are as follows (threshold values for establishing the risk category are formed as a result of analysis of industry publications [10][11][12][13][14][15][16][17][18][19][20][21][22][23][24][25]): if prh < 0.1, then the probability of risk rsph is very low (h = 1..k); if (prh ≥ 0.1)∩( prh < 0.25), then the probability of risk rsph is low (h = 1..k); if (prh ≥ 0.25)∩( prh < 0.5), then the probability of risk rsph is medium (h = 1..k); if (prh ≥ 0.5)∩( prh < 0.75), then the probability of risk rsph is high (h = 1..k); if (prh ≥ 0.75), then the probability of risk rsph is very high (h = 1..k).
• Determining the possible risk losses (how many losses. For each risk from the set RSP, the team of developers must set the amount of possible losses from its occurrence -in the range [0;1]. The set of risk losses has the form: LR={lr1,…,lrk}, where k is the number of risks of a particular software project. • Determining the magnitude of risk (mathematical expectation of damage). For each risk from the set RSP its magnitude of risk should be determined. The set of risk magnitudes has the form: MR={mr1,…,mrk}, where k is the number of risks of a particular software project, mri = pri ⋅ lri.
• Setting the priority level and ranking risks by priority. For establishing the level of priority and ranking of risks, let's find the maximal (mr_max) and minimal (mr_min) elements of the set MR. Let's further divide the received interval [mr_min; mr_max] at three intervals:
), [𝑚𝑚𝑝𝑝_𝑚𝑚𝑚𝑚𝑚𝑚 + 2⋅ 𝑚𝑚𝑚𝑚_𝑚𝑚𝑚𝑚𝑚𝑚−𝑚𝑚𝑚𝑚_𝑚𝑚𝑚𝑚𝑚𝑚 3
; 𝑚𝑚𝑚𝑚𝑚𝑚]. The rules for identifying the level of priority of risks are as follows:
if (mrh ≥ mr_min)∩(mrh < (𝑚𝑚𝑝𝑝_𝑚𝑚𝑚𝑚𝑚𝑚 + 𝑚𝑚𝑚𝑚_𝑚𝑚𝑚𝑚𝑚𝑚−𝑚𝑚𝑚𝑚_𝑚𝑚𝑚𝑚𝑚𝑚 3
)), then the level of risk priority rsph is low
))∩(mrh < (𝑚𝑚𝑝𝑝_𝑚𝑚𝑚𝑚𝑚𝑚 + +2⋅
𝑚𝑚𝑚𝑚_𝑚𝑚𝑚𝑚𝑚𝑚−𝑚𝑚𝑚𝑚_𝑚𝑚𝑚𝑚𝑚𝑚 3
)), then the level of risk priority rsph is medium (h = 1..k); if (mrh ≥ (𝑚𝑚𝑝𝑝_𝑚𝑚𝑚𝑚𝑚𝑚 + +2⋅ 𝑚𝑚𝑚𝑚_𝑚𝑚𝑚𝑚𝑚𝑚−𝑚𝑚𝑚𝑚_𝑚𝑚𝑚𝑚𝑚𝑚 3
))∩(mrh ≤ mr_max ), then the level of risk priority rsph is high (h = 1..k).
As a result of applying the above rules for identifying the level of priority of risks to all risks of the project we will have a set of priority risks (high priority), a set of secondary risks (medium priority) and a set of least risks (low priority) of the specific software project, which are offered to members of the project team as assistance in choosing measures to reduce or eliminate risks.
Stage 3. Risks planning:
• Risks reduction or elimination measures -a set of potential risks reduction or elimination measures PMR = {pmr1, …, pmr19}, where pmr1 -prior training of project team members; pmr2 -coordination of a detailed list of requirements with the customer; pmr3inclusion of the agreed list of requirements of the customer in the contract; pmr4 -exact compliance with the customer's requirements from the agreed list of requirements; pmr5preliminary market research; pmr6 -expert evaluation of the project by an experienced thirdparty consultant; pmr7 -consultations of an experienced third-party consultant; pmr8training to learn the necessary development tools; pmr9 -concluding an insurance contract; pmr10 -use of "template" solutions from successful previous projects in project management; pmr11 -preparation of documents showing the importance of this project to achieve the financial goals of the developer's company; pmr12 -reorganization of the project team so that the responsibilities and work of team members overlap; pmr13 -purchase (order) of part of the components of the developed software; pmr14 -replacement of potentially defective components of the developed software with purchased components that guarantee the quality of work; pmr15 -acquisition of a more productive database(s); pmr16 -use of the source code generator; pmr17 -reorganization of the project team depending on the level of complexity of tasks and professional levels of developers; pmr18 -reuse of suitable software components that have been developed for other projects; pmr19 -analysis of the feasibility of creating this software.
The rules for determining the measures to reduce or eliminate the risks of a particular software project and the forming the set PMRER of measures for a particular software project (one, the most appropriate, measure for each risk!) are as follows:
if the risk rspg can be reduced or eliminated by the measure pmr1, then pmr1 ϵ PMRER; if the risk rspg can be reduced or eliminated by the measure pmr2, then pmr2 ϵ PMRER; … if the risk rspg can be reduced or eliminated by the measure pmr19, then pmr19 ϵ PMRER. Stage 4. Risks monitoring:
• Risk assessments -all risk-related values are not constant in the project. The probability of a risk event and potential losses may increase and decrease as a result of risk mitigation or elimination measures. Therefore, estimates of the probability, damage and magnitude of risk after the application of such measures are required. For each risk from a set RSP, the development team must determine the probability (in the range [0;1]) of its occurrence after the application of the chosen measure to reduce or eliminate risks. The set of probabilities of risks after the application of measures has the form: PRA={pra1,…,prak}, where k is the number of risks of a particular software project. For each risk from the set RSP, the development team must determine the amount of possible losses (in the range [0;1]) from its occurrence after the application of the selected measure to reduce or eliminate risks. The set of risk losses after the application of measures is as follows: LRA={lra1,…,lrak}, where k is the number of risks of a particular software project. For each risk from the set RSP, it's necessary to determine its magnitude after applying the selected measure to reduce or eliminate risks. The set of risk magnitudes after the measures has the form: MRA={mra1,…,mrak}, where k is the number of risks of a particular software project, mrai = prai ⋅ lrai.
For example, let's consider a project to develop software for job search and recruitment. Stage 1. Risks identification. The analysis of the software project documentation showed that it lacks a description of quality and reliability characteristics, time performance characteristics, recommendations for future software maintenance, properties and possibilities of flexibility to change plans, project strategy and planning, project success forecasting. Then, according to the rules for determining the sources of risk: psr2 =1, psr3 =1, psr5 =1, psr6 =1, psr11 =1, psr14 =1, psr15 =1, psr18 =1, and the set PSR = {0, 1, 1, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0, 1}. Since psr2 =1, psr3 =1, psr5 =1, psr6 =1, there are technical risks. Since psr11 =1, there are plan risks. Since psr14 =1, psr15 =1, psr18 =1, there are risks of project management processes and procedures.
In addition, the analysis of the software project documentation showed that there may be reluctance of developers to use lifecycle support software, insufficient database(s) performance, defects and limited functionality of reusable software components, defective system components, changes and schedule violations work, underestimation of project time, low morale of staff, weak interaction between members of the development team, passivity and lack of competence of the project manager, inability to organize the necessary staff training, underestimation of the required number of developers, unrealistic forecasting of project results. Then, according to the rules for determining the risks for a particular program project: pre3 = «reluctance of developers to use lifecycle support software tools», pre6 = «insufficient performance of database(s)», pre7 = «reusable software components have defects and limited functionality», pre11 = «defective system components», pre18 = «changes in the work schedule», pre19 = «violation of the work schedule», pre22 = «underestimation of project time», pre28 = «low morale of staff», pre29 = «weak interaction between members of the development team», pre30 = «passivity of the project manager», pre31 = «insufficient competence of the project manager», pre36 = «inability to organize the necessary staff training», pre38 = «underestimation of the required number of developers», pre42 = «unrealistic forecasting of project results», and the set PRE = {0, 0, «reluctance of developers to use lifecycle support software tools», 0, 0, «insufficient performance of database(s)», «reusable software components have defects and limited functionality», 0, 0, 0, «defective system components», 0, 0, 0, 0, 0, 0, «changes in the work schedule», «violation of the work schedule», 0, 0, «underestimation of project time», 0, 0, 0, 0, 0, «low morale of staff», «weak interaction between members of the development team», «passivity of the project manager», «insufficient competence of the project manager», 0, 0, 0, 0, «inability to organize the necessary staff training», 0, «underestimation of the required number of developers», 0, 0, 0, «unrealistic forecasting of project results», 0}. Since pre3 =1, pre6 =1, pre7 =1, pre11 =1, there are technical risks. Since pre18 =1, pre19 =1, pre22 =1, there are plan risks. Since pre28 =1, pre29 =1, pre30 =1, pre31 =1, pre36 =1, pre38 =1, pre42 =1, there are risks of project management processes and procedures. According to the rules for forming the set of risks of a particular software project, the set RSP = {«reluctance of developers to use lifecycle support software tools», «insufficient performance of database(s)», «reusable software components have defects and limited functionality», «defective system components», «changes in the work schedule», «violation of the work schedule», «underestimation of project time», «low morale of staff», «weak interaction between members of the development team», «passivity of the project manager», «insufficient competence of the project manager», «inability to organize the necessary staff training», «underestimation of the required number of developers», «unrealistic forecasting of project results»}, k =14.
Stage 2. Risks analysis. For each risk from the set RSP, the development team identified the probability of its occurrence in the range [0;1]. The set of probabilities of risks has the form: PR={0.53, 0.71, 0.12, 0.15, 0.05, 0.13, 0.29, 0.41, 0.89, 0.76, 0.67, 0.91, 0.47, 0.03}. According to the rules for classifying risks according to their probabilities, we find that there are 2 risks with very low probability, 3 risks with low probability, 3 risks with medium probability, 3 risks with high probability, 3 risks with very high probability.
For each risk from the set RSP, the development team identified the amount of possible losses from its occurrence -in the range [0;1]. The set of risk losses has the form: LR={0.1, 0.5, 0.6, 0.3, 0.9, 0.5, 0.41, 0.96, 0.87, 0.76, 0.73, 0.74, 0.93, 0.94}.
For each risk from the set RSP it was determined its magnitude. The set of risk magnitudes has the form: MR={0.053, 0.355, 0.072, 0.045, 0.045, 0.065, 0.1189, 0.3936, 0.7743, 0.5776, 0.4891, 0.6734, 0.4371, 0.0282}.
Let's find the maximal mr_max and minimal mr_min elements of the set MR: mr_max =0.7743, mr_min =0.0282. Let's divide the resulting interval [0.0282; 0.7743] at three intervals: [0.0282; 0.2769), [0.2769; 0.5256), [0.5256; 0.7743]. According to the rules for identifying the level of priority of risks, we identify the level of priority and rank risks by priority: risk rsp 1 has a low level of priority; risk rsp2 has a medium level of priority; risk rsp3 has a low level of priority; risk rsp4 has a low level of priority; risk rsp5 has a low level of priority; risk rsp6 has a low level of priority; risk rsp7 has a low level of priority; risk rsp8 has a medium level of priority; risk rsp9 has a high level of priority; risk rsp10 has a high level of priority; risk rsp11 has a medium level of priority; risk rsp12 has a high level of priority; risk rsp13 has a medium level of priority; risk rsp14 has a low level of priority. In this case, the set of priority risks (with a high level of priority) consists of risks rsp9, rsp10, rsp12; the set of secondary risks (with a medium level of priority) consists of risks rsp2, rsp8, rsp11, rsp13 and the set of least risks (with a low level of priority) of a specific software project consists of risks rsp1, rsp3, rsp4, rsp5, rsp6, rsp7, rsp14.
Stage 3. Risks planning. According to the rules for determining the measures to reduce or eliminate the risks of a particular software project and the forming the set of measures for a particular software project, the set PMRER ={« training to learn the necessary development tools», «acquisition of a more productive database(s)», «reuse of suitable software components that have been developed for other projects», «replacement of potentially defective components of the developed software with purchased components that guarantee the quality of work», «consultations of an experienced third-party consultant», «exact compliance with the customer's requirements from the agreed list of requirements», «expert evaluation of the project by an experienced third-party consultant», «prior training of project team members», «reorganization of the project team depending on the level of complexity of tasks and professional levels of developers», «reorganization of the project team depending on the level of complexity of tasks and professional levels of developers», «reorganization of the project team so that the responsibilities and work of team members overlap», «use of "template" solutions from successful previous projects in project management», «consultations of an experienced thirdparty consultant», «consultations of an experienced third-party consultant»}.
Stage 4. Risks monitoring. For each risk from the set RSP, the development team determined the probability (in the range [0;1]) of its occurrence after the application of the selected measures to reduce or eliminate risks. The set of probabilities of risks after the application of measures is as follows: PRA={0.21, 0.1, 0.02, 0.02, 0.02, 0.03, 0.08, 0.1, 0.19, 0.14, 0.05, 0.41, 0.27, 0.01}. For each risk from the set RSP, the team of developers identified the amount of possible losses (in the range [0;1]) from its occurrence after the application of the selected measures to reduce or eliminate risks. The set of risk losses after the application of measures is as follows: LRA={0.1, 0.5, 0.2, 0.05, 0.9, 0.5, 0.41, 0.96, 0.1, 0.2, 0.1, 0.54, 0.93, 0.94}. For each risk from the set RSP, it was determines its magnitude after applying the selected measures to reduce or eliminate risks. The set of risk magnitudes after measures is as follows: MRA={0.021, 0.05, 0.04, 0.001, 0.018, 0.015, 0.0328, 0.096, 0.019, 0.028, 0.005, 0.2214, 0.2511, 0.0094}. Comparison of the sets MR and MRA allows us to conclude that after the application of selected measures to reduce or eliminate risks, the magnitude of risks has decreased significantly -Figure 1. Therefore, the proposed method of the software risks management makes it possible to identify sources of risk and possible risks for any software project, as well as to assess risks, determine their priority and measures to reduce or eliminate risks. In addition, the method allows risks assessment after the application of selected measures to reduce or eliminate risks, which makes it possible to select the best measure to minimize the magnitude of each risk. The presented method provides a mathematical basis for a risks management process, which reduces the complexity and increases the effectiveness of risk management.
The result of any project depends on the number and magnitude of risks of insufficient software functionality, non-compliance with project deadlines, budget overruns. The task of developers is to reduce and eliminate risks. Reducing the risks of a software project helps to increase its success, quality, efficiency and effectiveness. Therefore, risks management should be one of the foundations of project management, and the actual task now is to improve risk management in software development.
From the results of the analysis of the current state of the software development industry it follows that a promising area of research is the development of a mathematical basis or a method of risks management in software development. Therefore, the main task of this study is detailing and formalizing the method of the software risks management.. The paper proposes a method of software risks management, which allows identifying sources of risks and possible risks for any software project, as well as to assess risks, determining their priority and measures to reduce or eliminate risks. In addition, the method allows risks assessment after the application of selected measures to reduce or eliminate risks, which makes it possible to select the best measure to minimize the magnitude of each risk. The conducted experiment allows us to conclude that after the application of selected measures to reduce or eliminate risks, the magnitude of risks has decreased significantly. Herewith, the presented method provides a mathematical basis for a risks management process, which reduces the complexity and increases the effectiveness of risks management.
The prospect for further research by the authors is to develop a software risks management system, which will be based on the proposed in the paper method of the software risks management.