Risk management—identify, analyze and solve the risks in the development process of the educational administration information system in colleges and universities.

1. Experimental content and requirements

Identify, analyze and solve the risks in the development process of the educational administration information system in colleges and universities.

Through the risk management of the risks generated in the process of the university's educational administration information system, students can understand the necessity of risk management and experience how to identify risks, analyze risks, control risks and solve risks after the occurrence of risks in actual development.

Based on what they have learned, students can identify common risks that occur when developing an information management system and formulate corresponding mitigation plans and emergency plans by using common risk identification methods and past development experience.

Experimental tasks:

Task 1: Identify at least 5 risks in the project based on SEI risk classification, SWOT, information collection and other methods

Task 2: Analyze the risk and evaluate its probability (P) and impact (I)

Task 3: Develop a Risk Response Plan

Task 4: Develop a risk contingency plan

Task 5: Risk Tracking

Use the template below to document identified risks and track them

Risk ID		risk category		risk status
recognition time		Possibility (P)		degree of influence (I)
Risk intensity (RE)				priority
risk description
Avoidance/Mitigation Plan	time		personnel		principal
	content
	Implementation
emergency plan	Triggering conditions		personnel		principal
	content
	Implementation

2. Experimental method

(Introduction to Risk Identification Methodology)

• Document review: reviewing the software project plan, program and other documents and the work process and results of each project stage can identify many risks of the project.
• Earned value analysis: compare the planned work with the completed work to determine whether the project meets the planned cost and schedule requirements. If the deviation is large, further risk identification, evaluation and quantification of the project are required.
• Environmental analysis: analyze the environment of the project (including customers, competitors, partners, government managers, etc.), so as to identify project risks, and focus on the characteristics and stability of their interrelationships.
• Scenario analysis: Through relevant data and charts, etc., a certain state or situation of the project in the future is described and analyzed in detail, so as to identify the key factors that cause project risks and the degree of impact of risks. It focuses on explaining the conditions and factors that cause risks from certain events, and also explains what kind of risks will arise and what consequences will occur when certain factors change.
• Interviews: Interviews about risks with team members, experienced stakeholders, relevant experts, and those with similar project experience on software projects will help to identify those risks that are not identified in conventional methods.

3. Experimental results

(Risk Register)

Risk ID	01	risk category	Product size	risk status	Issue
recognition time	5/04	Possibility (P)	60%	degree of influence (I)	5
Risk intensity (RE)	higher			priority	1
risk description	The initial number of online active users of the product is 5,000, but when the educational administration system releases short-term content and requires resource downloads, the number of online active users exceeds 5,000
Avoidance/Mitigation Plan	time	5/04	personnel	project developer	principal	project development manager
	content	Use large servers
	Implementation	It can effectively buffer the situation where many people are online at the same time
emergency plan	Triggering conditions	More than 5000 online users	personnel	project developer	principal	project development manager
	content	Additional server resources
	Implementation	After a short period of time, the system resumed operation, supporting more than 5,000 people online at the same time

Risk ID	02	risk category	Unclear demand	risk status	Active
recognition time	5/7	Possibility (P)	80%	degree of influence (I)	5
Risk intensity (RE)	high			priority	2
risk description	The requirements are not detailed, the requirements description is not clear, and the requirements are not well considered
Avoidance/Mitigation Plan	time	5/7	personnel	Project Manager, Requirements Analyst	principal	project manager
	content	1. Write detailed requirements documents Write detailed requirements documents, you can discuss important requirements with development 2. Develop prototype diagrams Product managers use prototype development tools to develop prototype diagrams and visualize requirements
	Implementation	Effective, the demand has been relatively clear, the risk possibility is changed to "low", and the priority is "low"
emergency plan	Triggering conditions	Developers or users question the usefulness and feasibility of content related to the requirement	personnel	Project Manager, Requirements Analyst	principal	project manager
	content	Hold a requirement discussion meeting to collect more user requirements, cooperate with various departments, discuss these requirements together, clearly define the requirements, and arrange development priorities
	Implementation	Discuss the handling method and content adjustment in a short time, and deal with it effectively.

Risk ID	03	risk category	Number of staff and experience	risk status	Active
recognition time	5/10	Possibility (P)	60%	degree of influence (I)	4
Risk intensity (RE)	generally			priority	3
risk description	During the development process, the project members will resign, resulting in the inability to continue some work
Avoidance/Mitigation Plan	time	5/11	personnel	project developer	principal	project development manager
	content	When the project starts, be prepared for the turnover of personnel, and adopt some techniques to ensure that the project can continue once the personnel leave. Establish good project organization and communication channels to keep everyone informed about each relevant development activity. Specify documentation standards and establish mechanisms to ensure that documentation is created in a timely manner. Organize detailed reviews of all work so that most people can complete their work on schedule
	Implementation	The risk of personnel flow can be avoided in time, and the impact degree of the project is reduced to 3
emergency plan	Triggering conditions	A large number of people resign at the same time	personnel	project developer	principal	project development manager
	content	后备人才的培养，最好形成一个梯队，前面的人员离职之后，梯队后面的人能顶上来。 平常多组织大家相互交流项目开发经验让大家相互了解开发的项目内容。 核心功能的开发，可以分解成多个部分，分配给不同的开发人员来开发，不要集中在某个人身上。
	执行情况	有效处理人员流动，保证项目的顺利进行

风险ID	04	风险类别	技术情况	风险状态	Issue
识别时间	5/12	可能性（P）	60%	影响程度（I）	2
风险强度（RE）	较高			优先级	4
风险描述	采用新技术，可能制造未知的bug，从而降低软件的可用性，给你制造未知的bug，从而降低软件的可用性
规避/减缓计划	时间	5/13	人员	项目开发人员	负责人	项目开发负责人
	内容	开发过程中积极讨论新技术带来的bug，以及它的使用情况 调研大厂使用情况，规避出现的风险 少部分人进行新技术测试，保证新技术的实用性
	执行情况	有效能缓冲多人同时在线的情况
应急计划	触发条件	新技术导致进度延期	人员	项目开发人员	负责人	项目开发负责人
	内容	培训开发人员 找专家作指导 采取边开发边学习的方式，要求在规定时间内掌握
	执行情况	开发效果太差但能满足项目需求

风险ID	05	风险类别	人员数目及经验	风险状态	Issue
识别时间	5/13	可能性（P）	60%	影响程度（I）	4
风险强度（RE）	弱			优先级	3
风险描述	对需求的开发或系统标准没有合适的测试案例
规避/减缓计划	时间	5/17	人员	项目测试人员	负责人	项目测试负责人
	内容	项目启动时，做好一定的测试计划表，完成相关测试文档 开发过程中，跟随项目变更进行对应文档的更改
	执行情况	能够测试大部分的功能以及bug检测
应急计划	触发条件	测试无法实现全覆盖，不定时出现各类bug	人员	项目测试人员	负责人	项目测试负责人
	内容	找专业的测试公司进行测试
	执行情况	使得项目测试更具有针对性，测试更全面

四、实验心得

通过本次实验，我了解到不同的风险分析方式，对于风险识别方法可以通过文档评审、挣值分析、情景分析、面谈等方式，风险评估时进行风险发生概率的估计和评价，并对风险后果的严重程度进行评价，对于风险概率和影响程度的评估，我们可以组织包括软件项目团队成员、项目干系人和项目外部的专业人士等在内的人员，采用召开会议或进行访谈等方式，对风险发生概率和影响程度进行分析。同时可以采取洁决策树分析法进行图形化的概率分析也可采取SWOT方式进行预测，蒙特卡洛模拟法最常用。