软件项目中的风险识别的思考
在软件项目的开发过程中，我们必须要面对这样一个现实问题，就是风险无处不在。如果不能正确的识别和控制风险，那么点滴的疏漏就有可能把项目推向崩溃的边缘
首先，软件项目中的风险具有繁殖能力。如果不能识别项目中的初级风险，那么这个风险很可能在项目推进过程中衍生出其他风险。如用户需求定义过程，没有充分理解用户的意图或用户的操作习惯，而是想当然的定义用户的需求，那么就会给系统框架结构的设计或用户接口（UI接口）设计，埋下风险的种子。日后只要条件成熟，它们会遍地开花的。
其次，软件项目中的风险具有变异能力。虽然同类项目可以参照类比，但是，不能生搬硬套。不同的环境下，同样的风险会有不同的表现形式。如用户需求的定义，不同设计人员，定义的结果会就会发生差异。如果我们不能及时的发现和纠正这些差异，日后就有可能把项目推向一个进退两难的境地。
三，软件项目中的风险具有依赖性。项目中任何风险都不是独行侠，它们本质上是互相依赖，互为因果的。它们就像一张无形的网，如果你能找到正确的节点，那么很多风险都会被你破解在无形之中，如果找不到争取的节点，那么它们会越搅越乱，最后让你难以自拔。
那么如何识别软件项目中的风险呢？
从思想意识方面，要注重以下方面
1、 三四而后行，做一件事情之前，一定要想清楚前因后果，不但要有工作热情，更要有谨慎而科学的思考习惯；
2、 要有团队意识，我们知道任何个人的思维是有局限性的，软件作为一种知识密集性产品，我们需要能力强、素质高的个人，他们是团队的核心，但绝不排斥任何人对项目有益的思考和建议。
3、 要有良好的沟通交流意识，这种沟通交流不仅是项目组内部的，同时也要涵盖到项目的客户。做为开发人员，大多是专业技术人员，对项目的应用领域的知识知之甚少，容易一叶障目，因此与客户的沟通交流尤为重要。
人员管理方面，要注意一下问题
1、人员构成是否与项目的复杂度匹配，项目组不一定都得是强人，对于简单项目使用强人是浪费；对与复杂项目，没有强人是灾难；
2、项目组成员的是否稳定，稳定的团队，人员之间容易形成默契，有助于形成开发合力，提高开发效率和项目品质；
3、项目组成员的角色分工是否合理，每个人是否能够各尽所长，避己之短。
在实际开发过程中，要考查分析以下几个方面
一， 用户需求定义阶段
1、 功能的定义是否清楚，这里要求功能的界定不能具有二义性；
2、 是否有重复的功能定义；
3、 项目的应有范围和环境是否定义清楚；
4、 项目中涉及的工作流程是否定义清楚；
5、 软件系统中的需要消费和生产的数据是否定义清楚；
二， 系统设计阶段
1、 开发技术的选择是否合理，这里要坚持的原则是复杂的业务，要用简单的技术来实现，这样可以让开发人员有更多的经历来关注业务领域，而不是陷于复杂技术的泥沼；
2、 功能接口的定义是否合理，这里同样要坚持简单的原则，这样可以降低接口对接的复杂度，减少开发人员学习使用接口的时间，提高开发效率
3、 功能是否进行了原子化的分解设计，这里要坚持的独立的原则，也就是说每个任务单元要尽可能的单一，并且我们可以同这些单一的任务组合完成不同功能，这样可以提高代码的复用度，降低代码的耦合度；
三， 程序设计及编码阶段
1、 相关人员对作业范围内的业务概念是否全面掌握；
2、 相关人员对作业范围内的专业技术是否全面掌握；
3、 相关人员对于编码规范是否有全面的认识；
4、 Debug环境是否具备，对于大型并行开发的软件项目，很多功能存在依赖关系，要并行开发，势必有一些功能不具备在编码阶段进行Debug的条件，为了具备Debug的条件就要做一些模拟的工作，因此在工作量的计划上一定要充分的考虑；
5、 相关代码的品质检查标准和相关的责任者是否明确。
四， 测试阶段
1、 测试环境是否具备，特别是大型项目，由于并行开发和功能依赖或硬件设备的限制，测试时需要做大量的模拟工作，因此一定要在时间和人员给予保障；
2、 测试用例的设计是否合理，很多时候测试用例是由开发人员编制的，这样的用例容易把开发者的逻辑思维带到用例当中，使得测试用例陷入一个固定的思维模式，而成无效用例；
3、 测试数据中的状态数据是否涵盖应用领域的每一种状态，如果没有，则测试数据是不健全的，测试结果就会有误差；
风险是不可回避的，我们必须时刻关注项目进展过程中的缺陷和不足，时刻警惕着。
