First of all, a risk management plan must be made in the project development plan;

Second, the project budget must include the funds needed to solve the risks;

Third, when assessing risks, the impact of risks must also be included in the project plan.

Let's talk about the risks that often occur in the process of software development and the preventive measures we take.

1, the demand is not clear

Requirements ambiguity is a common problem in the process of software development, which is often manifested in many aspects, such as unclear requirements scope, unclear requirements, unclear requirements description, lack of requirements, and contradictory requirements. In all stages of the life cycle of software development process, the waste caused by unclear requirements is the greatest and must be solved as soon as possible. It is very difficult to determine the needs of users. We often deal with the problem of unclear needs from the following aspects:

(1) Let users participate in the development.

Provide a collaborative development environment for users to participate in the development process. If conditions do not permit, customers should be allowed to participate in the development at least in the requirements analysis and system testing stages of each iteration.

When selecting users to participate in the development process, on the one hand, we should strive for users who are proficient in business or computer technology to participate as much as possible. On the other hand, if the developed products are to be applied in enterprises of different sizes and types, representative users should be selected to participate.

It is not enough to let users participate, so we should take some incentive measures to improve the enthusiasm of users.

(2) Develop the user interface prototype.

Users are usually not good at describing their business requirements accurately, and system analysts need to use whiteboard, white paper and other communication methods to help users clearly express their needs. Then, develop a prototype user interface so that users can confirm the requirements. The function of user interface prototype is only to collect users' needs, and it should not be used for other purposes, nor should it give users the illusion that the system is about to be realized.

(3) Demand seminar

For projects with a wide distribution of users and a large number of users, it is often difficult to collect users' needs comprehensively, and demand research meetings are usually used to confirm the needs. A few weeks before the meeting, investigate the opinions of users in various localities and departments, and then convene users' representatives in various localities or departments to hold a demand seminar to collect demand through the meeting. This method is suitable for users who have some experience in using information systems.

(4) Strengthen demand analysis and review.

First of all, demand analysis is the foundation of the success of the project, which needs to be paid enough attention and allocated enough time and manpower. Experienced system analysts should be responsible, novices or programmers should not be responsible. Secondly, it is necessary to conduct requirements review, and let users participate in the requirements review as much as possible, instead of making the requirements review a mere formality. Third, and most importantly, the requirements statement that has passed the review must be signed by the user and become an annex to the project contract, which is binding on both parties. Within the company, the requirements specifications that have passed the review should be included in configuration management.

2. This project lacks popularity.

When a project manager or a developer says that 80% of the tasks have been completed, you must be cautious. Because the remaining 20% may take up 80% of the time, or even never be completed [1]. Software development projects usually lack visibility in terms of project schedule and software quality. The lower the visibility of the project, the more difficult it is to control and the more likely it is to fail. We can improve the visibility of the project through iterative development, technical review and continuous integration.

(1) iterative development

Using iterative development model, the product delivery process is divided into multiple stages, and the product is delivered incrementally according to the function. Here are some typical iterations:

Establish scale and prospect and determine the short-term pre-iteration of business reasons;

Elaboration iteration, during which a baseline will be drawn for a stable framework;

A build iteration, during which use cases will be implemented and the architecture will be enriched;

Several iterations of productization, transferring products to user groups.

Every iteration, we should fully receive users' comments and make self-correction. Progressive function delivery is the best progress report, which helps to reduce the pressure of developers, increase the satisfaction of users and enhance the visibility of the project.

(2) Technical review

Technical review is an important link to ensure software quality. Technical review includes code drill, meeting review and peer expert review. Code review can be a cross review between developers, or a review of ordinary developers by senior developers; Generally, the meeting will be reviewed at least once every two weeks, and the review time should not be too long; Peer expert review includes both technical experts and business experts. It is an important guarantee for the success of the project to let business-savvy user experts participate in the project review regularly.

In addition, making full use of the tool software of quality review is also beneficial to improve the code quality. For example, in the Eclipse development environment, you can integrate Findbug, Checkstyle and PMD plug-ins to check the quality of code writing.

(3) Continuous integration

Continuous integration can disperse the final large-scale integration debugging process to the weekly, daily or even hourly development progress of the project. So that all personnel in the project can keep abreast of the current overall progress and quickly find and solve problems during the integration process [1].

The development team should develop a continuously integrated system. Usually, in nightly builds, you can use Ant and other build tools to build Java applications. Team members should submit the code to the version control system (such as CVS) in time after each function is developed, and should not submit the code with problems (compilation failure) to the version control system.

Nightly build and continuous integration make it easier to track project progress. When the project team recompiles the system every day, the completed and unfinished functions are clearly visible, and the team members can simply know how far it is from the overall completion from the performance of the software.

3. Introduction of new technologies

Technological innovation is an exploratory and creative technical and economic activity. It is inevitable to encounter various risks when introducing new technologies in the development process. The risk of new technology can be reduced by T-software development, full demonstration, multi-stage evaluation and peer experience.

Development of (1) T-shaped software

In the early stage of project development, the development team should establish the system architecture, solve key technical problems, develop the basic components of the system, and conduct in-depth exploration of the technologies that the system needs to apply. For example, building a national online ticketing system based on JavaEE5 involves key issues such as distributed transaction processing, mass data storage, heterogeneous platform interconnection and so on. , priority should be given; The technologies involved in the development, such as EJB3, JSF, JBoss Seam, Eclipse RCP, need to be discussed in depth.

The more complex the project is technically, the sooner the technical problems should be solved. If there are architectural problems or key technical problems that cannot be solved in the middle and late stage of project development, it will be too late.

(2) Fully demonstrate

The development of new technology is an exploratory work with many potential failure risks. In the feasibility analysis stage, it is necessary to collect relevant information extensively, design a variety of feasible schemes and fully demonstrate them. When making decisions, the quantity and quality of information are very important. The more information you have, the more accurate you can make correct decisions, and the risk of project failure will be relatively reduced; On the contrary, the risk will increase.

(3) Peer experience

In view of the new technology, because there is no experience to learn from, we should make full use of the Internet in the process of exploration, and often get twice the result with half the effort by searching the experience of our peers. To make full use of this increasingly flat world, we can put aside the problems that cannot be solved as soon as possible, and there may be solutions to similar problems on the Internet in a few days.

4, technical compatibility risk

There may be compatibility problems between hardware products and system software (operating system, middleware and database management system) and host equipment, system software and application software. Generally, the more complex the system integration project is, the more likely the compatibility problem will appear.

(1) Design is preferred

When making the overall design scheme of the system, we must ensure the selection of related products and ensure that there is no big technical compatibility problem among the network, host, system software and application software. In the network platform construction scheme, the technical parameters and configuration requirements of related equipment are defined.

(2) Pre-sales product testing

When bidding for a project, bidders are required to provide product compatibility tests before sales to avoid exposing technical compatibility problems during project implementation. For integration projects involving application software development, technical compatibility tests should be conducted at the early stage of development to avoid exposing technical compatibility problems at the later stage of project development.

For example, in the development of Shenzhen bus terminal ticketing network scheduling system, in order to ensure technical compatibility, we require minicomputer equipment manufacturers to provide pre-sale technical compatibility tests when bidding for hardware, and take the test results as assessment indicators. When testing minicomputers provided by IBM, SUN and HP in Shenzhen Software Testing Center, many technical compatibility problems among application software, application server, database and operating system were exposed. If these problems are exposed or dealt with during the system implementation, the project progress will be delayed.

5. Performance issues

Due to the lack of early design, performance problems are often exposed after system switching or new systems are used for a period of time. Performance problems often require a lot of optimization work, even partial or comprehensive redesign. Neither users nor developers want performance problems.

(1) performance plan

When designing the system, we should do a good job in the early stage of performance planning and fully estimate the links that may have performance problems. When designing the database, we should strive for the participation of DBA.

In addition, in terms of technical methods, we try to adopt some performance optimization modes, such as DTO, AJAX, delayed loading and so on. , try to solve the performance problems in the development process. It is not expensive or time-consuming to solve the performance problem until the later stage of the project.

(2) Performance test

In the development process, we should attach importance to performance testing and stress testing, simulate the real use environment as much as possible, and build a test platform. In addition, because computers in the development environment are often configured higher than those in the production environment, we should try to find some machines with low configuration and small network bandwidth for testing.

(3) Sufficient debugging time

In the project development plan, there is room for later performance optimization. After system performance optimization, performance test and stress test are needed, and several regression tests may be done. So we should reserve enough time and manpower.

6. Rush online

In the process of project implementation, the system switching online link is the most prone to errors. The project was finally developed, but it collapsed at the last minute. If the project is small, the narrow influence area is not very important; If it is a project with a relatively large impact, there is definitely no problem. Before system switching, all possible problems should be fully considered and risk countermeasures should be taken.

(1) emergency plan

Facing all kinds of unpredictable risks, we should make emergency plans. The normal operation of the station ticketing system will make emergency plans during the Spring Festival travel rush peak and the Golden Week. When the new system is switched, an emergency plan should be made. Prepare for the worst in the emergency plan. When the ticketing system can't work normally, it is the worst plan to prepare manual ticketing.

(2) Step by step switching

In order to reduce the impact of risks, the system can be switched step by step. For example, when the ticketing system is switched, the new system is often used to sell advance tickets, or the new system is used to sell long-distance stations, and the old system is used to temporarily sell short-distance tickets. After the new system runs stably, switch to the new system completely. The system switching of multiple subscriber units can also be carried out by unit.

(3) Cross training

In the process of switching between old and new systems, users have an adaptation process. In addition to the operation training before switching, we should also do cross-training in the process of switching between old and new systems. Let users go to work a period of time in advance, let early shift users train middle shift users, and middle shift users train late shift users. Doing cross-training well can make the system transition in a balanced way.

7, usability problems

The availability of software includes many factors, such as whether the use of software is efficient, easy to learn, easy to remember, pleasant and error-prone. Often due to the poor usability of software, users are dissatisfied and even eliminated by the market. In project development, we should pay attention to usability problems and avoid software usability risks.

(1) Understanding users

Go to the user's work site, understand the real purpose of the target user to use the software, and from the user's point of view and standpoint, understand how to use the software system to replace the most complicated, most prone to problems or a lot of repetitive work in the user's business process, so that the software can improve the user's work efficiency and benefit. For example, in the ticketing system, the most commonly used interface is the ticketing interface, and the conductor is most concerned about not making mistakes in the money (more confiscation and less compensation). Therefore, the display and font change of accounts receivable should be prominent and eye-catching; Similarly, the fare and arrival should also be highlighted. Through shortcut keys, one-button reset, digital keypad and other designs. , try to reduce the number of times the conductor hits the keyboard. Otherwise, in a large passenger station with a daily passenger flow of 70,000 to 80,000, if the user interface is not well designed, the conductor will knock his fingers numb after a day's work.

(2) Participatory design

Cooperate with users, let users participate in the design, review and test of user interface, and ensure that users can find usability problems comprehensively and early, and correct them in time.

Let the customer participate in the design, not let the customer design, and the project manager or senior designer should lead the design.

(3) Competitiveness analysis

Through the analysis of similar competitive products in the market, or the experimental test of these products, we can understand the user interface problems of these products, thus providing enlightenment for the development of new systems. Competitive analysis does not mean that you can steal other people's designs, but by analyzing the advantages and disadvantages of competitive products, you can do better than the previous designs [5].

(4) Consistency

If users know that the same command or the same operation will always produce the same effect, they will be more confident when using the system, and encourage them to carry out exploratory learning, because they already have the basic knowledge of using new parts of the system [Lewis er al. 1989].

The development team should follow the user interface standards set by the company or the team, so as to maintain consistency in many aspects and prohibit a system from having multiple interface styles.

Zhengzhou Guanzhi E-commerce, with effective resources, many successful cases and professional production level, provides a series of services such as micro-futures platform construction, distribution system development, fishing game development, third-party payment software development, mall website construction, e-commerce website construction, website customization development, mobile app software development, WeChat applet development, e-commerce system development, office system software development and so on. The elite team will escort your future!

8. Conclusion

In the information system integration project, risks are varied and ubiquitous. In project management activities, we should actively face risks and cultivate them. The earlier risks are identified and managed, the more likely it is to avoid risks or reduce the impact when risks occur. Especially for complex projects with many participants, wide coverage, great influence and high technology content, risk management should be strengthened. If you don't take the initiative to control risks, you will face risks.