软件开发中的一些风险控制

    软件的风险其实就是软件失败的可能性，控制好的风险就是降低了软件失败的可能，定期总结如何控制软件开发中的风险，并在后续的开发过程中避免已知风险，不断总结积累，避免得越多，成功的可能就越大。

1. 需求阶阶段
1）充分沟通通，保证信息的完整性。
        需求人员一般与研发、工程人员是分开的，所以需求人员在调研需求时一般只倾向于对功能性的调研，而对性能、健壮性、系统约束等问题考虑可能欠缺。不可能要求需求人员对研发及工程人员关心的信息收集完整，所以在需求阶段需求调研人员必须与开发人员、工程人员充分构通，并不断补充各方面需要的信息，保证需求的完整性。
2）打通信息渠道，随时沟通。
    无论前期需求沟通再充分，都不可能获取到所有相关人员需要的全部信息，或多或少在开发过程中会需要一些前期未知的信息，这时最重要的是尽快通过信息渠道获取需要的信息。所以，在软件开发之前，打通信息渠道，准备随时与用户沟通是很必要的，可以防止项目意外中止，影响项目进度。
    当在开发中遇到需求中未明确的问题时不能想当然地采取任何决定，否则很可能开发出的软件不符合用户的要求。不要动不动就拿需求说事儿，最后用户提出说哪里不符合实际情况，就推辞说需求没有明确，推托责任是无济于事的，应该在出现需求不明确的时候立即想办法沟通，解决问题。

2.设计阶段
1） 充分设计，保持合理的扩展性。
    充分设计而不是过分设计，并不是要考虑所有可能的情况并都作为实现的目标，而是合理地考虑日后的扩展。认真分析用户需求，可能会发现一些日后用户很可能提出，但目前并未作要求的功能点，而这些功能点也很可能就是产品的增长点，充分设计为这些未来的增长点考虑扩展，其总体成本将会比不考虑扩展性要低很多，而且可以提高对用户的响应速度。

2）提前预研。
    在向用户承诺之前必须充分考虑技术的难度，必要时还要对关键技术难题进行预研，即使不一定做成原型，也要从技术上充分确定可行性，否则也将给项目带来重大延期风险，甚至造成灾难。
3）与用户充分沟通关键技术方案。
    我们有这么一次沉痛教训，我们的网管软件运行在用户的服务器上，为了保证信息的可靠传输以及模块间的松耦合，采用了文件接口（即各模块间使用文件进行数据传输）。当所有开发任务都完成了，找用户验收时，技术负责人却强令要求把文件接口改成UDP传输，没有任何商量的余地，因为此前曾经有过小文件堆满了服务器，删了很久（以天计算）都删不干净，严重影响了系统的运行；而且还有用TCP接口，结果网络一旦故障，不断重连导致系统资源消耗严重，影响了系统运营，所以只让用UDP协议了。没有办法，只得重新修改。
如果在一开始对一些重要的方案进行沟通，将不会导致返工的情况。
4）考虑系统约束。
    系统运行环境可能是非常复杂的，可能与我们的测试环境有着很大不同，测试环境中运行良好，到了生产环境未必能运行良好，甚至无法运行。比如网络环境，生产环境可能具有严格的网络限制，所以在设计方案时必须充分考虑这些约束，不能想当然。对于想到的约束，必须与用户充分沟通来确定，不能带着不确定进行开发。

3. 开发阶段
1）认真作计划。
    计划是必须充分评估项目的技术难度、人员能力、工作量等各因素制定出来的，不是拍脑袋拍出来的。以前就有一个领导制定月计划，然后随便安排几个任务，里面有些任务我都不知道要做什么，然后我问他要做什么，不知道，问题要用什么技术实现也不知道。这么一问三不知的工作就列出计划，能不能完成只能看运气了，结果计划分配的时间连实际用的时间的三分之一都不到，那个月绩效很低。如果一直跟着这样的领导，日子怎么能好过？制定计划就要负责的，为项目负责，为上级负责，也要为下属负责。
2） 保证人力的备份。
    对于一些要求紧急的项目，如果人力资源被100%用完，这将是项目一个极大的风险，一旦中途由于各种原因产生人员流动，届时再补充人手，也于事无补，反而可能会恶化项目进度。所以，在项目的任何一个阶段都应该保证充分的人力，除非对开发人员有200%的把握不会产生流失（怎么可能？）
3） 做好代码的备份。
    这个问题每一个项目管理者和开发者都懂，但却往往会被忽视。我就经历过一个沉痛的故事，那时还在学校，课题组买了服务器，做了RAID，防止硬盘损坏，而且的确中间出现过这个问题，由于用RAID也就没对项目造成什么影响。但后来有一次，课题组一个老师让学校一个论坛用我们的服务器作为WEB服务器，结果那个同学什么也不懂却把我们的服务器整个给FORMAT掉了！什么RAID也不好使了！当时我还在医院陪着重病的父亲，当一师弟给我打电话告诉我这个消息，真的有一种“万丈悬崖一脚登空，扬子江心断缆崩舟”的感觉，差点儿晕倒。所幸我们当是用了版本管理软件，把各个没有签入的手工合并一下就差不多了，但仍然造成了很大的麻烦。所以，任何时候都必须使用版本控制软件，并做好软件备份，因为硬盘是很不可靠的，还必须保证存储介质的可靠。
4）提前让用户验收。
    用户提出的需求未必就是用户真正想要的，而且细节上的调整也再所难免，所以当系统基本完成后，用户看到了系统很可能会进行修改，如果到期再找用户验收，将有很大风险导致不能按时验收通过。这点与敏捷方法中的让用户参与开发的思想也是吻合的。

再想到随时补充吧。