Keywords

Software development; Risk management; Software engineering; Software risk management

Introduction

One of the most beneficial innovations of the industrial revolution are computers. Computer as the technology of the age it has changed our lives a lot. Computers active and well realized to use it beneficially software, in which software projects are required needs to be managed like. Software project management first to define its management needs to be defined. Project management project activities to meet your needs knowledge, skills, tools and techniques to project implementation [1]. Project management, initiation, planning, through execution, monitoring, auditing and closing processes performed. Project manager from project management individually responsible. Project management, time, money, while making effective use of resources such as people and space It is the discipline of defining goals and achieving them. It Therefore, time, cost, scope and intangible can be classified as assets. Software Project Management is an important part of project management. Because software projects are more uncertain, they often involve more risk and need higher costs. This means that risk management is more essential problems in software projects. As part of this formal process, IT companies are ranked according to the effectiveness and efficiency of project management. To this end, it uses a five- tiered framework to prioritize improvement actions to increase the maturity of the software process: entry-level, repeatable, defined, controlled, and finally optimization. Achieving each milestone can be costly and time-consuming, but nonetheless provides a suitable roadmap for companies looking to implement good practices and make logical progress in improving the software development process. This strategy makes it possible to establish a link between an undesirable outcome whether it is abandonment of a project, too high-end costs for the company, or customer dissatisfaction and the best way to anticipate and avoid it [2].

Literature Review

The studies discussed in this article aimed at determining the stages of software projects and the type of risk they are exposed to. The ranking of the management stages and risks of software projects in order to realize the classification is given below.

Types of risks in software projects

Finding and managing risk is one of the most important issues in software projects. Effective software risk analysis allows for an effective software planning and implementation [3,4]. In the sources examined within the scope of this research, we can generally divide the five sections of the threats that arise in software projects.

Time risks: This is the form of risk that alter the advance of the project, appear from incorrect assignment of tasks and equipment, and consequently prevents or prevents the project from being completed on time. Cost overruns are often caused by erroneous project costs or project scope extension, resulting in budget (cost) threats [5].

Risks in management: It leads to project loss due to incorrect operation application caused by project managers and executors. These include misleading priorities, failure to fulfill liability, insufficient funding, insufficient expertise or inexperience. Recruiting personnel, not preparing resources and not being able to chat with one another the team and similar reasons. Loss of performance and consistency are the most common sources of technical threats. It is due to the constant change of demands, a loss of specialized methods, a project that needs crucial procedures, and a challenging project model.

Curriculum risks: The kind of risk arising from events beyond the project boundary and out of control. Risks arising from a decrease in capital or a change in customer priorities.

Software project stages

It is the path the software takes from planning, developing, testing and even ending its life. In fact, it can be called the life cycle of the software. Software Projects are realized in four stages [6].

Requirement’s analysis phase: At this stage, the practical and operating specifications of the software to be established are determined.

Design phase: The software is designed in detail and made ready for implementation. Implementation phase: Coding, compiling, debugging, creating human machine interfaces, defining databases and it includes activities such as placing in databases.

Test phase: Each software unit implemented is passed through an isolated unit test independently from other units.

Correction phase: It includes the correction of errors that occurred in the previous stage and the activities that ensure the efficient operation of the system.

Methodology

In this article, 20 different source projects were examined for studies on risk management in software projects [7,8]. The resource distribution of the examination results according to the stages determined in the previous section is shown in Figure 1.

Figure 1: Risk management resource in software projects stage percentage in screening.

the "Maintenance and correction" phase has been intensely included in the studies. Again, according to the same, "Requirements" is the least studied development stage compared to other stages (4 studies, 12%) (Figure 1).

This is followed by "Design" and "Application" 5 studies (15%) equally. "Maintenance and remediation", on the other hand, is the most studied development stage in the research (34%).

In Figure 2, the distribution of the studies according to the developmental stages and stages is shown.

Figure 2: Software project risk management in resource search tier value distribution.

Types of risks considered in risk management studies in software projects as seen in Figure 3, in 10 of 20 studies, cost risks have been the most studied subject with a rate of 27%. With an average of 21% following that, management risks were addressed, technical and time risks were likewise, it followed them evenly with an average of 18% and the least important risk type was the software risks arising from the program code with an average of 16%.

Figure 3: Rate of risk types addressed in software projects.

Software projects are handled according to resources. The numbers of risk types are shown (Figure 4).

Figure 4: Handled by resources in software projects numbers of risk types.

Matching result: As can be observed, the most common stage of risk management that needs to be examined is maintenance. The least studied stage is software development requirements. In fact, this is a serious vulnerability that will affect risk management. However, software projects are more important than all projects [9].

The fact that it is affected by the risks that occur in the early stages seriously affects the cost and project success.

Visibility result: The software project risk management studies used for matching focused on some common issues and criteria [10]. Recognize that risk management is greater than just an action or technique, such as project management, that is implemented over time in an enterprise through learning, execution, and other processes.

It is a developed real-time risk management skill [11]. Risk management does not only cover the identification, assessment, mitigation and adherence to terms strategies and implementation issues of risks. It also includes the ability to respond quickly and effectively to emerging dangers. Whether these hazards were anticipated or not, they have the opportunity to have a huge impact on the project's outcomes.

According to the results of the analysis, it has been observed that risk management skills play an important role in the management of software projects [12]. Conceptualizing and developing the risk and risk management theory in analysis requires the uncertainties faced by software projects to be clearly identified. As a result of this process, it has been observed that the application difficulties that may arise in the management of the threats related to the software project can be eliminated.

One of the challenges of risk management practice in organizations is that managers are often focused on demonstrable results related to performance. If a significant the proposal is a success, it is difficult to unquestionably base the outcome or any part of it on risk management. It is extremely unusual to attribute project success to risk management as well. Instead, success depends on a good trend overall [13]. Sometimes it depends on luck. In these cases, some people claim to be successful because of their abilities and their distinctness contribution to the project. As a consequence, a company that has completed a project successfully can overlook the value of risk management in subsequent projects and thereby fail to incorporate risk management processes.

Finally, with a hands-on strategy, managements, it is not customary to search for the delay of implementation requirements. Researchers consider risks of effective practices from observations. They learn and generalize them with the necessary developing information. Researchers would not be able to meet the demands of risk analysts and project managers. Rather, use your knowledge of what happens and what doesn't in particular circumstances and situations. In cases where accessed do not improve project performance, new ideas should be tried. In this way, applications will encourage people to research. Among the issues discussed in software projects other than risk management, and the issues that may cause risks are generally due to the following reasons as a result of the research [14].

Managing projects: Contradictory observations in research may raise questions about the traditional perspective of project management as a systematic science based on well-defined processes and procedures that are essential for project progress. For example, any picture of whatever type in a project is formatted. Although the project management methodology or practices were not used, it was successful and, in another project, it failed despite all project management rules [15]. As mentioned earlier, project management is necessary but not sufficient for success. These observations, contrary to the findings of the article, may raise questions as if project management, as a formally defined term, established, is essential for project success. This is the official project; it is consistent with a view that supports the claim that its management leads to better project results [16].

Change of management: Many projects in research may encounter application and user-related problems due to improper management of institutional effects (almost 70% of projects dealing with administrative risks have not explicitly included management change in their scope). Rather than developing a new commercial solution, these programs typically saw their task as developing a software framework. Managing the change's operational effects is essential in these situations is perceived as a separate responsibility, or it is required by the cases user to be resolved after the project is concluded.

Since the beginning of the project, when successive organizational changes are managed well, projects are faced with less implementation problems. In these cases, the project enables a computing option and mandates a mandatory institutional change [17].

Project setup: Many projects may run into owing to a faulty project setup, there are issues. Activities that are crucial determined to make a good start of a software project are as follows; the most suitable project design and determining the development method, establishing the appropriate budget, collecting the requisite money, choosing the appropriate vendor partners, and evaluating the risks realistically. Risk from strict plan-based methods, for example, when the compatibilities are high and/or the scopes are rather uncertain and problems arose. In addition, some projects have been constrained by fund allocation arrangements that allow the project to end up incorrectly from the outset, allocating funds before the project costs are fully known. Other risks and issues are those that do not comply with commercial purposes that add value or this occurs when the project set-up is left to a dominant vendor, whose primary actions are more directed towards their own interests [18].

Qualitative risk analysis: This is a process in which the probability of realization and the strength of certain risks are assessed not by mathematical values, but by verbal logic, based on the experience and intuition of a practitioner. Descriptive values such as high, very high, and very urgent are used in place of numeric values when calculating and expressing an estimated risk. In such methods, the intuition and judgment of the assessor are important in terms of the reliability of the method [19]. For this reason, it is incorrect to carry out risk assessment only by qualitative methods in critical systems. Qualitative risk analysis process inputs, risk management plan, identified risks, project status, project type, data accuracy, risk probability values and impact values as in Table 1. When making assumptions with, outputs are generated using common risk assessment metrics. a list of risk priorities, a comprehensive analysis and a list of risks for management and the results of a qualitative risk analysis.

Table 1: Probability values used in qualitative risk accounts.

As a result of the risk probability and impact assessment, it is possible to reveal the general risk threat ranking of the project, the trends of the risks and the prevention ideas by using tools and techniques such as creating probability and potency matrix, detailed analysis of assumptions, data accuracy ranking (Table 1).

Risks can be classified as follows according to their impacts, they may increase or change according to the structure of the project [20].

Quality Risks: Risks of not reaching the desired performance level are exemplified in Table 2.

Table 2: Quality impact values used in qualitative risk accounts.

Time Sheet Risks: Risks of not being able to complete the tasks on time are exemplified in Table 3.

Table 3: Cost impact values used in qualitative risk accounts.

Cost Risks: Risks of not being able to complete the project within the allocated budget.

Scope Risks: Risks that need scope change or correction (Tables 2 and 3).

In calculating the degree of risk from the above probability and impact values, it is calculated as follows. Degree of risk=Likelihood of occurrence of a dangerous event *Impact of the danger [21].

Quantitative risk analysis: It is a numerical method of analysis that expresses the likelihood of certain risks and their impact on project activities in numerical form, these values are processed numerically and logically, and the risk value is determined. These numerical methods can be simple methods, such as probability and reliability theorems, or complex methods, such as simulation models [22]. The risk is calculated as follows. Risk level=likelihood of a hazardous event occurring* Hazard impact=Cost, duration, quality, scope, etc. Typically, this analysis is carried out after a qualitative risk determination, because in a qualitative risk analysis study, risks are prioritized according to their likelihood and levels of exposure. Quantitative risk analysis highlights high-risk risks and grades risks according to threat severity using techniques such as sensitivity analysis, decision tree analysis, expert opinion and Monte carlo simulations, estimated completion time and project cost, or compliance capability. the planned duration of the project and the budget. The values obtained are as a result, an updated list of risks is obtained. Project duration and budget have been updated. This estimates how much additional resources should be reserved for budget and total time [23].

Results

The literature on risk assessment in software projects has been discussed in this article. According to inquiries, risk control is a project management method that includes sub-processes such as project management is a real-time hazard management skill. Risk management studies show that the earlier the risk is identified and intervened, the more likely it is to prevent project failure and cost loss. While most of the research focuses on the post-onset stages, it has been observed that less work has been done in the stages before starting the research. In this research, 20 research projects related to software project risk management have been examined and compared. According to the matching result, the "maintenance and correction" phase in risk management has been the most studied subject. In terms of "budget and time", software is the projects most affected by risks compared to other issues. It has been observed that definition and management of risk in software projects are limited only by theory in most of the research. Transforming risk studies into practice in existing software projects. It will give more efficient results in conducting research.

Discussion and Conclusion

This study proposes an approach to defining the method to choose for risk analysis and software development project management. The proposed method is tested by example and the results are discussed. After reviewing the existing project management system, post-project analysis and risk management processes were developed as part of the project management process used and incorporated into the ongoing project management process. Both post-project analysis and risk management processes have been helpful in converting hidden information into explicit and written information. To take advantage of this opportunity, a knowledge base was developed and implemented in practice. It has been observed that most of the post-project analyzes are associated with risks. In other words, in the process of project management, minimizing or nullifying the negative difference between plan and implementation is considered as the absolute result of planning, implementing and monitoring this management area. Risk management includes steps that can achieve project objectives in terms of quality, time, cost, and scope with the least waste. The distribution of responsibilities and roles identified during the planning stage among people who have been involved in similar tasks or projects provided important insights into identification and analysis of risks. The potential risks that can be encountered while performing activities differ for each activity, as the risk in some activities with low impact on the project as a whole may have a low impact on the project as a whole, despite the risk assessment in the impact probability table, the risks that may arise in each of the project activities and the likelihood and impact of these risks were assessed separately from the point of view of the project objectives. After calculating the cost and duration of the project objectives, the project was evaluated more numerically. After risk analysis, a strategy for responding to risks considered as high risks was identified and implemented, taking into account the analysis of losses and benefits. Risk management costs are reflected in the project budget; The introduction of risk management at the planning stage of the project helped to calculate the budget more accurately. The strategies identified for the risks are tracked during the project, with the help of an alert mechanism, you can see the change in the final risk level of the state in the risk registry repository and the ability to make the necessary intervention after receiving the project. Any negative consequences that may arise during the project are monitored and precautions can be taken before they become a risk. This means that you need to allocate a budget to cover possible risks. Every work done in this direction has a positive impact on the project and, if possible, risks can be prevented before they arise. In software projects in the future, high number of risk management researches will increase the production of successful projects. For this, the following points should be considered. First, the risk should be limited as a probability of impact and by definition. In addition, project managers Need to be more aware of the severity of the possible consequences. It should be known that the impact in question can be an issue that needs to be evaluated in terms of both anticipated and unforeseen hazards. Better quality risk in software projects. It can be predicted that it would be more efficient to fully implement risk practices in line with the current view than to adopt the assessments. The second point is that, based on the literature visibility, the complexity of risk management is compared to the possible threats that software projects might face. It should be considered that it is rather narrow and a broader and integrated perspective in risk management may be more appropriate. The research has shown that more research is needed in terms of risk and project management convergence, as well as the relationship between the two in execution There are many sources of risk in both studies and programs, and each project has its own set of risks. It has been observed that the studies required to define it are specific to the scope of the project.

References

1. Erdem OA, YOUNİS AE (2012) Yazılım Projelerinde Risk Yonetimi. Bilişim Teknolojileri Derg 5: 1-6.
2. Kwan TW, Leung HK (2011) A risk management methodology for project risk dependencies. IEEE Trans Softw Eng 37: 635-648.
3. Hu Y, Zhang X, Sun X, Zhang J, Du J et al (2010) A unified intelligent model for software project risk analysis and planning. In 2010 3rd International conference on information management, innovation management and industrial engineering 4: 110-113.
4. Sadiq M, Rahman A, Ahmad S, Asim M, Ahmad J (2010) EsrcTool: A tool to estimate the software risk and cost. In 2010 second international conference on computer research and development 1: 886-890.
5. Sherer SA (1995) The three dimensions of software risk: technical, organizational, and environmental. In proceedings of the twenty-eighth annual hawaii international conference on system sciences 3: 369-378.
6. Gupta D, Sadiq M (2008) Software risk assessment and estimation model. In 2008 international conference on computer science and information technology 1: 963-967.
7. Chess B, McGraw G (2004) Static analysis for security. IEEE Sec Pri 2: 76-79.
8. Hosseingholizadeh A (2010) A source-based risk analysis approach for software test optimization. In 2010 2nd International conference on computer engineering and technology 2: 601-602.
9. Kajko-Mattsson M, Nyfjord J (2008) State of software risk management practice. Int J Comput Sci 35: 1-4.
10. Misra SC, Kumar V, Kumar U (2006) Different techniques for risk management in software engineering: A review. In conference of the administrative sciences association of Canada 1: 196-205.
11. Peng Y, Kou G, Wang H, Wang F, Ko S (2009) Empirical assesment of classifiers for risk assessment of applications. Int J Inf Technol 8: 749-767.
12. Dedolph FM (2003) The neglected management activity: Software risk management. Bell Labs Tech J 8: 91-95.
13. Fan CF, Yu YC (2004) BBN-based software project risk management. J Syst Softw 73: 193-203.
14. Cao P, Chen F (2009) A risk control optimization model for software project. In 2009 International conference on computational intelligence and software engineering 1: 1-4.
15. Foo SW, Muruganantham A (2000) Software risk assessment model. In proceedings of the 2000 IEEE international conference on management of innovation and technology 2: 536-544.
16. Wang YH, Jia J, Qu Y (2010) The “Earth-Moon” model on software project risk management. In 2010 International conference on machine learning and cybernetics 4- 1999-2003.
17. Zhang X, Yu B, Zhang J (2009) The application of fault tree analysis in risk assessment of applications. IEEE International conference on management of innovation and technology 1: 1-4.
18. Keil M, Cule PE, Lyytinen K, Schmidt RC (1998) A framework for identifying software project risks. Comm ACM. 41: 76-83.
19. Xiaosong L, Shushi L, Wenjun C, Songjiang F (2009) The application of risk matrix to risk assessment of applications. Glob Forum Inf Technol Appli 1: 480-483.
20. Mishra A, Mishra D (2009) Effective communication in collaboration and extreme programming coordination: A human-centered strateg in a small cases. Hum Factor Ergon Man 19: 438–456.
21. Jorgensen M, Grimstad S (2012) Software development estimation biases: The role of interdependence. IEEE Trans Softw Eng. 38: 677-693.
22. Asklund U, Bendix L (2002) A study of configuration management in open source software projects. IEE Proc Softw 149: 40-46.
23. Sharp H, Woodman M, Hovenden F (2005) Using metaphor to analyse qualitative data: vulcans and humans in software development. Empir Softw Eng 10: 343-365.