Experiences in software development project risk management

1. Preface
People who have participated in large software projects will realize that many things may go wrong. Once an error occurs, it may bring harm, loss, or other adverse effects to the project. Risks are the possibility of a series of events or adverse results in the project. Software development is a high-risk activity, which may be at any stage of the project development process. Proactive risk management can make the project process more stable, achieve high project tracking and control capabilities, avoid and transfer risks, or mitigate the adverse effects of risks. Risk management is a process of identifying, analyzing, responding to, and monitoring project risks. It is an important management activity in project management, effective Implementation of Software Risk Management ensures the smooth completion of software project development. Risk management must be achieved by three elements: first, a risk management plan must be developed in the project development plan; second, the project budget must include the necessary funds to address risks; and third, the impact of the risk must also be included in the project plan.

Next we will talk about the common risks in the software development process and the preventive measures we have taken.

2. unclear requirements
Unknown requirements are common problems in software development, these problems are often manifested in the following aspects: Undefined demand scope, not refined demand, unclear Requirement Description, missing requirements, and conflicting requirements. During the various stages of the software development process, unclear requirements lead to the greatest waste and must be addressed as soon as possible. It is very difficult to determine user requirements. We often start from the following aspects to deal with unclear requirements:

(1) involve users in development

Provides a collaborative development environment for users to participate in the development process. If the conditions are not allowed, the customer should at least participate in the development in the demand analysis and system test phases of each iteration.

When selecting users who participate in the development process, on the one hand, we should try our best to win the participation of users who are proficient in business or computer technology. On the other hand, if the products to be developed need to be applied in different scales and types of enterprises, representative users should be selected.

It is not enough to allow users to participate. Incentives should be taken to increase the enthusiasm of users.

(2) Develop a user interface prototype

Users are usually not good at describing their business needs accurately. system analysts need to use whiteboard, White Paper, and other communication methods to help users clearly express their needs. Then, develop a user interface prototype so that the user can confirm the needs. The role of the user interface prototype is only to collect user requirements. It should not be used any more, nor give users the illusion that the system is about to be implemented.

(3) Demand discussion meeting

For projects with a wide distribution of users and a large number of users, it is often difficult to fully collect user requirements. Generally, demand research and design meetings are used to confirm the needs. By investigating the user requirements and opinions of various localities and departments in the weeks before the meeting, we will then gather user representatives from different regions or departments to hold a Demand seminar to collect requirements through the meeting. This method is suitable for users with experience in information systems.

(4) strengthen demand analysis and review

First, requirement analysis is the foundation for project success. It requires enough attention and sufficient time and manpower to be allocated. Experienced system analysts should be responsible, rather than new project beginners or programmers. Second, we need to conduct a demand review, so that users can participate in the demand review as much as possible. Do not let the demand review flow in the industry. Third, and most importantly, the requirement specification should be signed by the user and used as an attachment to the project contract by both parties. In the company, the qualified requirement specification should be included in the configuration management.

3. The project lacks visibility.
When a project manager or developer says that 80% of the tasks have been completed, you must exercise caution. Because the remaining 20% may require 80% of the time, or even never [1]. Software development projects often lack visibility in project progress and software quality. The less visible a project is, the more difficult it is to control the project and the more likely the project will fail. We can enhance project visibility through iterative development, technical review, and continuous integration.

(1) iterative development

The iterative development model is used to divide the product delivery process into multiple stages and deliver products incrementally according to the functions. The following are typical iterations:

A brief preliminary iteration to establish the scale and prospects and determine the business reasons;

A refined iteration will define a baseline for a stable architecture;

One build iteration will implement use cases and enrich the architecture;

Several product iterations to transfer the product to the user group.

Each iteration should fully receive the comments from the user for self-correction. The progressive feature delivery helps reduce the stress on developers, increase user satisfaction, enhance project visibility, and be the best progress report.

(2) technical review

Technical review is an important part of ensuring software quality. Technical Review includes code inspection, meeting Review, and peer expert review. Code review can be a cross-disciplinary review between developers, or a senior developer's review of common developers. The meeting Review should generally be conducted at least once every two weeks, and the review time should not be too long; peer expert review includes technical and business experts. Frequent participation of business-proficient user experts in the project review is an important guarantee for the success of the project.

In addition, making full use of the quality audit tool software can also improve the code quality. For example, in the eclipse development environment, you can integrate the findbug, checkstyle, and PMD plug-ins to check the coding quality.

(3) continuous integration

Continuous integration can distribute the final large-scale integration debugging process to every week, every day, or even every hour of the project development schedule. This allows all personnel in the project to keep abreast of the overall progress and quickly discover and solve problems arising during the integration process [1].

The development team should develop a continuous integration system, which is generally constructed once a day and can use ant and other building tools to build Java applications. After each function is developed, the team members should promptly submit code to the version control system (such as CVS), and should not submit problematic code to the version control system.

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

4. Introduction of new technologies
Technological innovation is an exploratory and creative technological and economic activity. Introduce new technologies in the development process and inevitably encounter various risks. New technology risks can be reduced through T-shaped software development, full demonstration, multi-stage review, and peer experience.

(1) T-shaped Software Development

In the early stages of project development, the development team should establish a system architecture to solve key technical difficulties, develop basic components of the system, and conduct in-depth exploration of the technologies required by the system. For example, building a nationwide online ticketing system based on javaee5 involves distributed transaction processing, massive data storage, and heterogeneous platform interconnection. These problems should be prioritized; in-depth exploration is required for the ejb3, JSF, JBoss Seam, eclipse RCP and other technologies involved in development.

 

Figure 1 development system skeleton with "T" in the first stage [2]

The more technically complex the project is, the sooner the technical difficulties should be handled. If architecture problems or key technical difficulties cannot be solved in the middle or later stages of project development, it is too late.

(2) fully demonstrated

The development of new technologies is a highly exploratory task, and there are many potential risks of failure. In the feasibility analysis stage, relevant information should be collected extensively, multiple feasible solutions should be designed for full demonstration. When making decisions, the quantity and quality of intelligence are critical. The more information you have, the more accurate you can make the right decisions. The risk of project failure is reduced. On the contrary, the risk is increased.

(3) peer experience

Because there is no experience to use for new technologies, we need to make full use of the Internet in the process of exploration, and often get twice the result with half the effort by searching for experience from peers. To make full use of the increasingly flat advantages of the world, you can first release problems that cannot be solved as soon as possible. In a few days, there may be solutions to similar problems on the Internet.

5. Risks of technical compatibility
Between hardware products, between system software (operating system, middleware, database management system) and host equipment, between system software, between application software and system software, and between application software, there may be compatibility issues. The more complex the system integration project is, the more likely the compatibility problem exists.

(1) design first

When designing the overall system design scheme, make sure that the selection of related products is disabled to ensure that there is no major technical compatibility problem between the network, host, system software and application software. Define the technical parameters and Configuration Requirements of related equipment in the network platform construction scheme.

(2) pre-sales product testing

When bidding for a project, the bidder is required to provide product compatibility tests before the project is launched to avoid exposing technical compatibility issues during project implementation. For integration projects involving application software development, technical compatibility tests should be conducted in the early stages of development to avoid exposing technical compatibility issues in the later stages of project development.

For example, in order to ensure technical compatibility, we require minicomputer equipment vendors to provide pre-sales technical compatibility testing during hardware bidding when developing the ticketing and station Affairs Online Scheduling System of Shenzhen bus passenger stations, the test results are used as evaluation indicators. When the Shenzhen Software Testing Center tested the minicomputers provided by IBM, sun, and HP, it exposed the technical compatibility issues between many application software, application servers, databases, and operating systems, if these problems are exposed or handled during system implementation, the project progress will inevitably be delayed.

6. performance problems
Due to insufficient preliminary 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, or even partial or comprehensive re-design. No one, regardless of the user or developer, wants to have performance problems.

(1) performance planning

During system design, performance planning should be prepared in the early stage to make sufficient estimates for potential performance problems. DBAs should be involved in database design.

In addition, in terms of technical methods, try to adopt some performance optimization modes, such as DTO, Ajax, and delayed loading, to solve the performance problem during the development process as much as possible. The performance issue will not be solved until the end of the project, which is both costly and time-consuming.

(2) Performance Testing

During the development process, we should pay attention to performance testing and stress testing, simulate the actual use environment as much as possible, and build a testing platform. In addition, because the computer in the development environment is often higher than the computer in the production environment, you should try to find machines with low configuration and smaller network bandwidth for testing during the test.

(3) Sufficient debugging time

There is room for later performance optimization in the project development plan. After optimizing the system performance, perform performance tests and stress tests, and perform regression tests several times. Therefore, we should have enough time and manpower.

7. Rush to launch
During the project implementation process, system switching and launch are the most likely to cause leakage. The development of the project was completed, but the project failed at the last moment. If the project is small, it is not very important to narrow down the impact area; if it is a project with a large impact area, it should not be a problem. Before switching the system, we should fully consider various possible problems and take appropriate risk measures.

(1) Emergency Plan

In the face of all kinds of unpredictable risks, contingency plans should be prepared. Emergency plans will be prepared for the normal operation of the station ticketing system during the Spring Festival and Golden Week of tourism. Contingency plans should be prepared for new system switching. The worst plan should be prepared in the emergency plan. When the ticket sales system cannot work normally, preparing manual tickets is the worst plan.

(2) step-by-step Switching

To reduce the impact of risks, you can implement a step-by-step system switch. For example, when the ticket sales system is switched, it often uses a new system to sell pre-tickets, or a new system to sell long-distance stations, and the old system to sell short-distance tickets temporarily. After the new system runs stably, switch to the new system. System switching for multiple user units can also be performed in units.

(3) cross-training

During the switching between the old and new systems, users have an adaptation process. In addition to the operation training before the switchover, cross-training should also be conducted during the switchover between the new and old systems. Allow users to go to work some time in advance, so that early shift users can train users in the middle shift and users in the middle shift to train users in the late shift. Cross-training can balance the system transition.

8. availability issues
The availability of software includes the efficiency of software use, whether it is easy to learn, whether it is easy to remember, whether it is pleasant, whether it is easy to make mistakes, and many other factors. The availability of software is poor, which leads to user dissatisfaction and even elimination by the market. Pay attention to availability issues during project development to avoid software availability risks.

(1) understand users

Go to the user's work site to learn the real purpose of the target user's use of the software, from the user's perspective, from the user's standpoint, and how to replace the user's business processing process through the software system, the most tedious, problematic, or repetitive processes enable the software to improve user efficiency and efficiency. For example, in the ticket sales system, the most frequently used interface is the ticket sales interface. The conductor is most concerned about not making mistakes in money (the ticket is confiscated and lost). Therefore, the display of receivables and remaining fonts should be highlighted. Similarly, the fare and arrival site should also be highlighted. With the shortcut key, one-Click Reset, and keypad, the ticket conductor can minimize the number of times the keyboard is hit. Otherwise, if the user interface is poorly designed for large passenger stations with daily passenger traffic of 80 thousand or passengers, the ticket conductor will be numb to his fingers after a day's work.

(2) participatory design

Collaborating with users to participate in the design, review and testing of user interfaces, ensuring that users can discover problems such as availability in an all-round way and correct them in a timely manner.

Let the customer participate in the design, rather than let the customer design, the Project Manager or senior design personnel should lead the design.

(3) Competitive Analysis

By analyzing similar competitive products on the market, or conducting experimental tests on these products, you can understand the user interface problems of these products to inspire the development of new systems. Competitive analysis does not mean that you can plagiarize others' designs. Instead, by analyzing the strengths and weaknesses of competing products, you can do better than previous designs [5].

(4) Consistency

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

The development team should follow the user interface standards set by the company or group to maintain consistency in many aspects. Do not use different interface styles for a system.

9. Conclusion
In information system integration projects, risks are diverse and ubiquitous. In project management activities, we must actively face risks and cultivate them. The sooner you identify and manage risks, the more likely you are to avoid risks or reduce the impact of risks. In particular, risk management should be strengthened for complex projects with a large number of participants, wide coverage, large impact, and high technical content. If you do not take the initiative to control risks, you will face risks.

 

This article from the csdn blog, source: http://blog.csdn.net/yawolf/archive/2008/07/13/2646259.aspx