Thoughts on Risk Identification in software projects

In the process of software project development, we must face such a real problem that risks are everywhere. If you cannot correctly identify and control risks, a few omissions may push the project to the verge of collapse.
First, risks in software projects can be multiplied. If the initial risk in the project cannot be identified, this risk may lead to other risks during the project promotion process. For example, if a user's requirement definition process does not fully understand the user's intention or user's operation habits, the user's needs are defined, then, the system framework structure or user interface (ui Interface) design will be provided, laying the seeds of risk. In the future, as long as the conditions are ripe, they will blossom everywhere.
Secondly, risks in software projects are mutable. Although similar projects can be referenced in analogy, they cannot be difficult to implement. In different environments, the same risk may have different forms. Such as the definition of user requirements, different designers, the results of the definition will be different. If we cannot promptly discover and correct these differences, it is possible to push the project into a dilemma in the future.
3. Risks in software projects are dependent. Any risks in the project are not independent. They are essentially mutually dependent and mutually causal. They are like an invisible network. If you can find the correct node, many risks will be cracked by you. If you cannot find the desired node, then they will become more and more messy, and finally make you unable to extricate yourself.
How can we identify risks in software projects?
In terms of ideology, we should pay attention to the following aspects:
1. Think twice before you do things. Before you do something, you must be clear about the cause and effect. Not only do you have to be enthusiastic about your work, but you must be cautious and Scientific;
2. To be team-aware, we know that any individual's thinking has limitations. As a knowledge-intensive product, software requires a strong individual with high abilities, they are the core of the team, but do not reject anyone's thoughts and suggestions on the benefits of the project.
3. Have a good sense of communication and communication, which should not only be within the project team, but also cover the customers of the project. As developers, most of them are professional technicians who have little knowledge about the application field of the project and are easy to understand. Therefore, communication with customers is particularly important.
For personnel management, pay attention to the following issues:
1. Whether the composition of personnel matches the complexity of the project. The project team may not necessarily be a strong person. It is a waste to use strong people in simple projects. It is a disaster to have no strong people in complex projects;
2. whether the members of the project team are stable, stable teams, and personnel are easy to form a tacit understanding, which helps to form a Development Cooperation force and improve development efficiency and project quality;
3. Is the division of roles of project team members reasonable? Can each person do his/her best to avoid weaknesses.
In the actual development process, the following aspects should be examined and analyzed:
I. user requirement definition stage
1. is the definition of the function clear? The definition of the function is not necessary here;
2. Whether repeated function definitions exist;
3. Whether the scope and environment of the project are clearly defined;
4. Whether the workflow involved in the project is clearly defined;
5. Are the data to be consumed and produced in the software system clearly defined;
Ii. System Design Stage
1. Is the selection of development technology reasonable? The principle to be adhered to here is that complicated businesses should be implemented with simple technologies, in this way, developers can have more experiences to focus on the business field, rather than being stuck in the mud of complex technologies;
2. Is the definition of functional interfaces reasonable? Here we also need to adhere to the simple principle, which can reduce the complexity of interface connection, reduce the time for developers to learn to use interfaces, and improve development efficiency
3. Whether or not the function has undergone atomic decomposition design. Here we must adhere to the independent principle, that is, every task unit should be as single as possible, in addition, we can combine different functions with these single tasks to improve code reusability and reduce code coupling;
Iii. Programming and coding stage
1. are related personnel fully familiar with the business concepts within the scope of their work;
2. are related personnel fully familiar with the professional technologies within the scope of their work;
3. Relevant personnel have a comprehensive understanding of coding specifications;
4. Whether the debug environment is available. For large-scale parallel development software projects, many functions have dependencies. To develop them in parallel, some functions are bound to be unavailable for debugging in the coding stage, some simulation work is required to meet the debugging conditions, so we must fully consider the workload plan;
5. Check whether the quality inspection standards of relevant codes and the persons responsible are clear.
Iv. Test phase
1. Check whether the testing environment is available, especially for large projects. Due to parallel development and functional dependency or hardware limitations, a lot of simulation work is required during testing, therefore, it is necessary to provide time and personnel support;
2. Is the design of test cases reasonable? In many cases, the test cases are compiled by developers. Such use cases can easily bring the developer's logic into the use cases, this puts the test case into a fixed mindset and makes it an invalid use case;
3. Check whether the status data in the test data covers every state in the application field. If not, the test data is not sound and the test results are inaccurate;

Risks are unavoidable. We must always pay attention to the defects and deficiencies in the project progress and be always vigilant.