Project risk project risk refers to the potential budget, progress, human (staff and organization), resources, customers, and needs, and their impact on software projects. Technical risks threaten the quality and delivery time to develop software. Business risks threaten to develop software's ability to survive. Business risks often hazard projects or products. Five major business risks are: (1) Developed an excellent product or system (market risk) that no one truly needs; (2) The product developed is no longer in line with the company's overall business strategy (strategy risk); (3) It has built a product that does not know how to sell products; (4) Due to the focus of transfer or personnel's changes, senior management support (management risk); and (5) did not get budget or human guarantees ( Budget risk). It is important to note that simple classification is not always available. Some risks cannot be predicted in advance. / Identification risk is to try to systematically determine the threat to the project plan (estimation, progress, resource allocation). One way to identify risks is to establish a risk entry checklist. · Product size - risk related to the overall scale of software to be built or to be modified. · Business impact - risk associated with constraints added to management or market. · Customer Properties - Risk related to the quality of our customers and the ability of developers and customers regularly communicate. • Process Definition - Risk related to the extent that the software process is defined and the levels they have complied with the organization. · Development Environment - Risk related to the availability and quality of tools used to build products. · Construction technology - risk associated with "novelty" related to the complexity of the software to be developed and the technology of technology. · Number of personnel and experience - the overall technical level of software engineers participating in the work and the risk of project experience. / Risk prediction, also known as risk estimation, attempting to assess the possibility or probability of each risk-risk occurring from two aspects, and if the risk occurs, the consequences. Project planners, as well as other managers and technicians, implement four risk prediction activities: (1) establish a scale to reflect the possibility of risk of risk; (2) Describe the consequences of risk; (3) Estimating risk pair And product influence; (4) Large the overall accuracy of risk prediction to avoid misunderstanding. Risk Forms provide a simple risk prediction technique for project managers (risk tables should be implemented using spreadsheets so that the contents in the table are easy to manipulate and sort). / Risk assessment in this step in risk management, we have established a series of three-ing group [cha89]: [ri, li, xi] where RI indicates the risk, and XI means risk production. Impact. During the risk assessment process, we further review the accuracy of the estimated estimation in the risk prediction phase, trying to discharge priority for the discovered risk, and began to consider how to control and / or avoid possible risks. To make the assessment, you must define a risk reference level value [cha89]. For most software projects, risk factors, cost, support, and progress discussed earlier - also expressed risk reference standards. That is, for performance, cost overrun, support difficult, or progress delay (or combinations of these four), there is a level value requirement, exceeding it will lead to the termination of the project. If the problem caused by the combination of risks causes one or more reference level values to be exceeded, the work will stop. In software risk analysis, the risk reference level value has a point, called a reference point or a critical point, decided to continue the project or terminate it (the problem is too big) at this point (the problem is too big) is acceptable.
