关闭

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

标签: 服务器扩展任务web服务项目管理网络
3005人阅读 评论(0) 收藏 举报
分类:

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

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

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

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

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

再想到随时补充吧。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:679150次
    • 积分:9975
    • 等级:
    • 排名:第1796名
    • 原创:299篇
    • 转载:37篇
    • 译文:0篇
    • 评论:273条
    最新评论