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

原创 2011年01月23日 16:03:00

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

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

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

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

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

再想到随时补充吧。

相关文章推荐

软件开发项目风险管理的几点体会

参与过大型软件项目的人都会认识到许多事情都可能出错,一但出错就可能给项目带来危害、损失或其它不利影响。风险是在项目中发生的一系列事件或不利结果的可能性。软件开发是一项 高风险的活动,在项目开发过程的...

《软件开发规范》——风险控制

  • 2009年01月03日 09:30
  • 215KB
  • 下载

软件开发项目的风险分析与控制

  • 2015年01月12日 23:43
  • 155KB
  • 下载

软件开发项目风险管理的几点体会

参与过大型软件项目的人都会认识到许多事情都可能出错,一但出错就可能给项目带来危害、损失或其它不利影响。风险是在项目中发生的一系列事件或不利结果的可能性。软件开发是一项高风险的活动,在项目开发过程的任何...
  • e_wsq
  • e_wsq
  • 2011年11月28日 23:57
  • 745

管理软件开发项目关键风险

1.人员流失风险 考虑了下,还是把人员流失作为项目第一大风险,软件项目管理最重要的还是人的因素。特别是关键项目成员流失可能会导致整个项目的重大延期和失败。人的职业过程中主要受到金脉,知脉和人脉三个因...

一次迭代式开发的研究:软件开发的风险

我们的软件开发存在着巨大的风险,当我们经历了数月的辛苦工作后才发现,我们的软件并不是客户满意的软件。这时候往往出现几种情况: 1.客户开始频繁挑刺,大量的需求变更在很短的时间发生,加班再所难免...

管理软件开发项目关键风险

1.人员流失风险 考虑了下,还是把人员流失作为项目第一大风险,软件项目管理最重要的还是人的因素。特别是关键项目成员流失可能会导致整个项目的重大延期和失败。人的职业过程中主要受到金脉,知脉和人脉三个因...

软件开发的风险管理

  • 2014年03月04日 18:20
  • 524KB
  • 下载

软件开发风险

  • 2014年07月24日 11:09
  • 19KB
  • 下载

软件开发基于禅道版本控制规范

文档信息 文档名称 版本控制规范 电子文档 版本控制规范.doc 文件状态 □ 草    稿     ■正式发布    □ 正在修改 编 写 人 毛同彬...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:软件开发中的一些风险控制
举报原因:
原因补充:

(最多只允许输入30个字)