What Are the Different Types of Risk Management Software?

Software project risk management is an important content of software project management. In software project risk management, identify risks, evaluate their probability and impact, and then establish a plan to manage risk. The main goal of risk management is to prevent risks. Software project risk refers to budget and schedule problems encountered during the software development process and the impact of these problems on the software project. Software project risk will affect the realization of the project plan. If the project risk becomes a reality, it may affect the progress of the project, increase the cost of the project, and even make the software project unrealizable.

Software project risk management

Right!

Software project risk management is an important content of software project management. In software project risk management, identify risks, evaluate their probability and impact, and then establish a plan to manage risk. The main goals of risk management are

General introduction

If you manage the risk of the project, you can minimize the risk. However, domestic software companies do not care much about software

Risk in the project

The risks of software projects are nothing more than the following four aspects: requirements, technology, cost, and schedule. Common risks in IT project development are as follows:

Demand risk

Demand has become the project benchmark, but demand continues to change; Poor definition of requirements, and further definitions will expand the scope of the project; Add additional requirements; The ambiguous part of the product definition takes more time than expected; Insufficient customer participation in doing demand; Lack of effective demand change management process.

Planning risk

The definitions of plans, resources and products are based on verbal instructions from customers or upper-level leaders, and are not completely consistent; The plan is optimized and is the "best state", but the plan is unrealistic and can only be regarded as the "expected state"; Use a specific team member, and that particular team member can't really count on it; The size of the product (number of lines of code, function points, and percentage of the previous product size) is larger than estimated; The completion date is ahead of schedule, but there is no Adjust the product range or available resources accordingly; Involved in unfamiliar product areas, spending more time on design and implementation than expected.

Organize and manage risk

Only management or market personnel make technical decisions, resulting in slow planning progress and prolonged planning time; Inefficient project team structure reduces productivity; Management review and decision cycle is longer than expected; Budget cuts and disruptions Project plan; The management made a decision to combat the enthusiasm of the project organization; Lack of necessary specifications leading to work errors and duplication of work; The work of non-technical third parties (budget approval, equipment procurement approval, legal review, Safety guarantee, etc.) time is longer than expected.

Personnel risk

Tasks that are a prerequisite (such as training and other projects) cannot be completed on time; Poor relations between developers and management, resulting in slow decision-making and affecting the overall situation; Lack of incentives, low morale, and reduced production capacity; Some people need more time to adapt to software tools and environments that they are not familiar with; New developers are added at the end of the project, and training and communication with existing members are gradually required, which reduces the work efficiency of existing members; Conflicts between project team members, resulting in poor communication, poor design, interface errors, and extra duplication of work; members who are not suitable for work have not been transferred from the project team, affecting the enthusiasm of other members of the project team; not found The project urgently needs people with specific skills.

Development environmental risks

The facilities were not in place in time; The facilities were in place but not matched, such as no telephone, network cable, office supplies, etc. The facilities were crowded, cluttered or damaged; The development tools were not in place; The development tools were not as effective as expected People need time to create a working environment or switch to new tools; The learning period for new development tools is longer than expected and the content is extensive.

Customer risk

The customer is not satisfied with the final delivered product and requires redesign and redo; The customer's comments are not accepted, which causes the product to fail to meet the user's requirements and must be redone; The customer's decision-making cycle for planning, prototype and specifications It is longer than expected; The customer does not or cannot participate in the review of the planning, prototype, and specification stages, leading to unstable demand and changes in the product production cycle; The time for the customer to respond (such as the time to answer or clarify requirements-related questions) Expectations are long; Poor quality of components provided by customers leads to additional testing, design and integration work, and additional customer relationship management work.

Product risk

Correcting unacceptable products with low quality requires more testing, design, and implementation than expected; Developing additional unnecessary functions (gold plating), extending the schedule; Strict requirements for compatibility with existing systems, requiring Perform more testing, design, and implementation than expected; requires connection to other systems or systems that are not under the control of the project team, resulting in unpredictable design, implementation, and testing; in unfamiliar or untested software And unexpected problems arising from operation in the hardware environment; developing a brand new module will take longer than expected; reliance on technology in development will extend planning progress.

Design and implement risk

The design quality is low, resulting in repeated design; Some necessary functions cannot be implemented using existing code and libraries, and developers must use new libraries or develop new functions by themselves; The quality of code and libraries is low, resulting in the need for additional Test, correct errors, or remake; Overestimated the savings of enhanced tools for planned progress; Modules developed separately cannot be effectively integrated and require redesign or production.

Process risk

A large amount of paper work causes the process to be slower than expected; The quality assurance behavior in the early stage is unreal, leading to repeated work in the later stage; Too informal (lack of compliance with software development strategies and standards), resulting in insufficient communication and poor quality Good, and even need to be re-developed; Too formal (adhering to software development strategies and standards dogmatically), resulting in too much time-consuming and useless work; Writing a process report to management taking up more time for developers than expected; Risk Careless management leads to failure to detect significant project risks.

Risk identification

Identifying risks is the systematic identification of known and predictable risks, avoiding them when possible, and controlling them when necessary. According to the risk content, we can divide the risk into:

(1) Product scale risk: Risks related to the overall size of the software.

(2) Business impact risk:

Boehm model

Boehm uses the formula RE = P (UO) * L (UO) to define risk, where RE represents the risk or the impact of the risk, P (UO) represents the probability of an unsatisfactory result, and L (UO) Denotes how destructive a bad result can be. In terms of risk management steps, Boehm basically follows the traditional project risk management theory, pointing out that risk management consists of two major parts: risk assessment and risk control. Risk assessment can be divided into three sub-steps of identification, analysis, and priority setting. Risk control It includes the three steps of developing a management plan, solving and monitoring risks.

The core of Boehm's thinking is a list of 10 risk factors, including staff shortages, unreasonable schedules and budgets, and constant demand changes. For each risk factor, Boehm provides a series of risk management strategies. In actual operation, based on the list of 10 major risks, summarize the specific risk factors of the current project, plan and implement after the assessment, and summarize the resolution of the 10 major risk factors at the next regular meeting to generate new ones. Of the top 10 risk factors, and so on.

The idea of the top 10 risk list can effectively focus management's attention on the high risk, high weight, and key factors that seriously affect the success of the project, without the need to consider many low-level details. Moreover, this list has been compiled and compiled through in-depth investigations of several large aerospace or defense system software projects in the United States, so it is universal and practical. However, it is only based on the induction of the set of risk factors, and there has been no article discussing its specific theoretical basis, raw data and its induction method. In addition, Boehm did not clearly explain which special aspects of software risk the risk management model should capture, because the listed risk factors will change with multiple risk management methods and also affect each other. This means that the risk list needs to be improved and expanded, and management steps need to be optimized.

Although there are some shortcomings in its theory, Boehm can be said to be the pioneer of software project risk management after all. Since then, more organizations and individuals have started to study risk management, and the importance of software project risk management is increasingly recognized.

CRM model

SEI (Software Engineering Institution), as the world's famous organization to improve software engineering management practices, has also invested a lot of enthusiasm in risk management. SEI proposed the Continuous Risk Management (CRM) model.

SEI's risk management principles are: continuously evaluate factors that can cause bad consequences; determine the most urgently needed risks; implement strategies to control risks; evaluate and ensure the effectiveness of risk strategy implementation.

The CRM model requires attention to risk identification and management at all stages of the project life cycle. It divides risk management into five steps: risk identification, analysis, planning, tracking, and control. The framework shows the basic activities of applying CRM and the interactions between them, emphasizing that this is a sequence of activities that are repeatedly performed during the project development process. Each risk factor generally needs to go through these activities in order, but different activities for different risk factors can be concurrent or alternating.

Leavitt model

Both SEI and Boehm's models take the process of risk management as the main body, and study the reference information required for each step and its operation. The idea proposed by Aalborg University is based on the Leavitt model, focusing on exploring risk management from different perspectives leading to software development risks.

The Leavitt model proposed in 1964 divides the organizations that form various systems into four interesting components: tasks, structures, roles, and technologies. These four components correspond well with the various factors of software development: the role covers all project participants, such as software users, project managers, and designers; the structure represents the project organization and other institutional arrangements; the technical principles Includes development tools, methods, hardware and software platforms; tasks describe the goals and expected results of the project. The key idea of the Leavitt model is: the various components of the model are closely related. Changes in one component will affect other components. If the state of one component is inconsistent with the other, it will cause more serious consequences, May degrade overall system performance.

Correspond this model to the concept of software risk, that is, any modification of the Leavitt components during the development of a system will cause some problems and even cause the software modification to fail. According to the Leavitt model, any factor that causes risk can be attributed to the components of the model, such as technology and its feasibility; or the relationship between the components, such as the ability of a program developer to use a technology. Therefore, using the Leavitt model to identify and analyze the risks of software projects from four aspects is extremely methodical and comprehensive. In software project management, different methods can be used for risk management in different aspects.

The Leavitt model is actually a framework that can organize the information about software risks more extensively and systematically. Leavitt's theory of design methods and implementation research has been widely used in information systems. It considers all very important aspects of software risk management, and is simple, well-defined, and suitable for analyzing risk management steps.

to sum up

In short, during software project development, when software expectations are high, risk management such as project risk analysis, forecasting, evaluation, management, and monitoring are generally performed. Risk management can make the project process more stable, can obtain a high ability to track and control the project, and can enhance the project team members' confidence in the project to complete as scheduled. Risk management is a very important management activity in project management. Effective implementation of software risk management is a guarantee for the successful completion of software project development.