软件项目风险可能产生的原因

需求：

　　最初的风险是来自需求调研，与用户的沟通也是从需求开始，正确把握好需求，才能鉴定清楚项目目标。
　　在需求整理后，一定要与用户多次进行沟通确认，确保我们整理的需求就是用户希望的，确保需求调研完整、覆盖面全。
方案：

　　针对需求，要提出合适的实现方案，该方案必须保证可扩展性、适当性（与项目组实际情况符合），不能因为方案涉及太复杂，造成研发负担。
　　方案确定后要与用户确认，项目组提出的方案是符合项目组的要求的，但不一定符合用户的需求，比如硬件设施是否能够满足，人员是否能够配备齐全。又用户确认才能通过。
系统架构：

　　采用符合该项目的架构，满足需求、以现有资源容易实现，工作量不大。架构设计由项目组成员一起讨论后才能确定。
项目规范：

　　一个新开始的项目必须进行统一规范，没有一个统一的规范，项目进行久了，就会乱。也无法进行评估大家的工作。
系统概要设计：

　　概要设计必须以需求为基础进行设计，根据实际的使用系统的用户来考虑，将权限、角色先定义清楚，然后划分功能模块。
　　概要设计完后必须进行项目组评审，需求人员、测试人员、研发人员参与讨论。概要设计必须含盖了所有的需求。概要设计完要出UI原形，供用户评审。
系统详细设计：

　　在概要设计的基础上进行，不可以偏离需求，还要兼顾项目组研发人员的水平能力，保证满足需求的前提下，最小工作量实现即可。
　　详细设计检查，由研发人员进行，由测试人员参与，达到编码可实现，测试可进行即可。
测试用例：

　　由测试人员负责，根据需求、详细设计进行，必须含盖90%以上的需求，以详细设计为基础进行。
测试用例必须项目组主要人员评审，检查是否覆盖需求，是否与需求符合，是否包含了用户实际工作中的情况。
编码：

　　有研发人员进行，前提要先熟悉需求，对需求理解正确，跟踪详细设计进行，并编写单元测试，单元测试的正确性要提交文档进行评审。
测试：

　　测试人员根据测试用例进行功能性测试，系统发布前自动进行单元测试或由负责人跑测试用例。测试报告供大家评审。
系统发布：

　　发布必须保证资料全部是最新的，保证测试都是通过了的，该版本还存在什么缺陷。发布只能由统一的产品经理负责，统一编版本号，保证发布的产品是唯一的、正确的。

 

留做记录，希望朋友们提出与风险控制有关的内容。