1、文档目的

软件在其生命周期内的各个环节都具有不确定性和复杂性，存在一定的风险。随着现代化科技技术的发展，各领域的需要日益增多，如何变被动为主动，对软件项目的风险进行识别，掌控软件项目的风险具有十分重要的现实意义。

软件项目风险控制应贯穿于整个软件开发过程，重视风险、学会正确处理风险，合理规避风险，调整应变成本，可将风险发生的可能性减小到最低，也能将风险发生带来的损失尽可能降至最低。

此文档着重介绍了软件开发过程中所涉及到的人员、流程、技术、环境、需求、产品以及设计和实现等方面所面临的风险以及它们的规避方法。

2、风险

2.1 人员风险

风险	解决方案
我们组有五个人，其中编程能力较好的有两人，所以软件开发的主要代码由他们二人负责编写，任务较重、压较大、完成时间难以掌握。	尽可能将项目的核心工作分派给多人，培养和加强各成员的代码编写能力。
某些成员需要更多的时间适应还不熟悉的软件工具和环境。	所有成员都要尽快熟悉的软件工具和环境，基础好的成员多帮助基础较差的成员，大家共同进步，分担压力。
如果项目组成员之间发生冲突可能会导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作。	发生矛盾时要及时讨论并解决问题，成员间要互相理解、理性分析，确保项目顺利进展。
缺乏适当的激励措施，成员可能会因为长时间的工作（如：修改代码错误）而情绪低下导致效率降低。	建立一定的鼓励措施，分阶段制订几个小目标。目标完成后对完成目标的主要人员进行一定的物质奖励。
熟悉各种操作较慢的成员完成工作的时间以及任务比重，可能会影响项目组其他成员的积极性。	根据各成员较为擅长的项目决定项目分工，合理组织项目组成员，使他们有效地分工协作、共同完成项目建设。
文档编写与软件开发双方若沟通不良会影响项目顺利进展。	项目组成员应明确沟通方式和沟通渠道，确保沟通畅通，信息及时互通。
由于技术人员不足或技术人员水平或人员沟通等等原因导致代码编写的完成时间难以掌握。	招募项目所需的技术人员，从而优化和提高代码质量，缩短完成周期，使项目完成时间可控。

2.2 流程风险

风险	解决方案
开发过程中每个人负责板块不同，编程风格不同,导致沟通不足,质量欠佳,甚至需重新开发	使用迭代开发，将开发过程分为多个阶段，将每个阶段的开发任务分给不同的组员，该开发阶段中，开发人员专注开发，在模块开发完成后未分到开发任务的组员进行测试和功能报告的撰写保证虽然每个人负责的板块不同但对他人写的模块都有所了解
撰写进程报告占用开发人员的时间比预期的多

2.3 技术风险

风险	后果	解决方案
不理解三层架构，经验不足过度使用某些技术（如xml,web webservice）、业务规则和逻辑混在一起。	（１）按照２层经验去设计三层架构，一个不好的经验导致整个系统瘫痪（２）过度使用xml,web service导致性能严重不佳（３）一个页面写５,6千行代码，无法维护，缺乏可伸缩性	将结构简化，同时借鉴同行经验，取其精华改进，明确需求和所需功能，防止算法逻辑混乱。
对主机没有做好提前规划，急于上线	运行一段时间后系统资源不足，必须重新规划	对于主机提前做好全局规划，预留维护空间。
业务（数据）架构不合理（查询、插入操作放在一起）	查询、插入需要不同的优化方式	将查询和插入操作分为两个模块来实现。
测试不全面	用户成了试验田	在正式上线前进行严谨的软件测试，寻找用户参与测试，使得软件更成熟。
陈旧的开发过程，没有每日集成，未及时与客户确认功能实现	上线临近出现一大堆无法解决的问题	采用W型开发，需求开发测试同步进行，增加容错率，及时解决问题。
未做好集中压力测试	并发时系统崩溃	做好压力测试，防止系统奔溃，必要时进行服务器扩容。
没有好的架构，缺乏好的开发规范	程序bug重多，代码很难维护，代码水平依赖程序员水平。解决方案：规范代码格式，书写编程日志，在适合的框架下编写代码，减少工作量。	规范代码格式，书写编程日志，在适合的框架下编写代码，减少工作量。
缺乏数据库规划	噩梦般的熬夜调优、维护	建立数据库前做好规划，规范数据库格式。
脱离现状的设计	满足不了客户要求	采用W型开发，需求开发测试同步进行，逐步满足客户的需求，减少不必要的资源浪费。
没有真正理解java多线程、对象、继承、垃圾回收机制等等；没有真正理解JDBC、没有真正理解Ｊ２ＥＥ、sevelet、JSP、MVC	造成可靠性、可维护性、可伸缩性、性能问题。	提升自身实力，寻找精通的人才加入。
操作性、友好性不好	很难使用、业务员抱怨成堆、实施异常困难	很难使用、业务员抱怨成堆、实施异常困难解决方案：做好用户体验报告，及时更新改善操作性友好性问题，进行多次调试，多轮测试。

2.4 环境风险

风险

解决方案

工作环境（包括办公环境和人文环境）

工作环境（包括办公环境和人文环境）的好坏直接影响项目成员的工作情绪和工作效率。

预防这种风险的办法是在项目建设之前就选择和建设好适合项目特点财务管理和满足项目成员期望的办公环境、在项目的建设过程中不断培育和调整出和谐的人文环境。

系统运行环境风险

目前，大部分项目系统集成和软件开发是分开进行的（甚至由不同公司承接）。因此，软件系统赖以运行的硬件环境和网络环境的建设进度对软件系统是否能顺利实施具有相当大的影响。

预防这种风险的办法是和用户签定相关的协议、跟进系统集成部分的实施进度、及时提醒用户等。

2.5 需求风险

产品开发过程中，由于产品需求本身的隐含性、用户与开发者之间的沟通障碍，以及需求随着时间、用户的变化而变更等原因，可能使需求分析偏离实际需求而最终导致产品开发的失败，这种可能性称为需求风险。软件开发项目风险是指在软件生命周期中所遇到的所有的预算、进度和控制等各方面的问题，以及由这些问题而产生的对软件项目的影响。需求分析是软件开发过程中最初始、最基础的工作，也是最重要的工作之一，其成败将直接并最终决定软件开发的成败，并且呈倍增效应。需求分析的关键是使隐含的需求明确，使变更的需求可控，采用座谈会、需求调查表、需求启发、角色扮演等方法可以使需求明确化；采用面向对象的方法及UML工具、领域专家的全程参与、需求分级、二次开发接口等方法可以使需求变更处于可控范围内。实践证明，这些都是控制需求风险的有效方法。

风险	解决方案
没有足够用户参与	对系统用户及用户的替代源等相关涉众进行准确的分析；采用问卷调查等简单的需求获取方式或对于参与用户提供一定的奖励政策。
需求已经成为项目基准，但需求还在继续变化	对于合理的用户需求可以将新需求放到后续版本中；对于不可理的用户需求，需要开发人员保持业务领域的专业性。
模棱两可的市场需求	通过多用户或了解用户背景的方式来分析用户的深层目的，明确隐藏在背后的需求
不必要的特性	对于不必要的特性要摒弃
过于精简的规格说明	同时使用模型语言和自然语言两种表达方式，同时保证信息传递的准确行和文档的可读性。
被忽略的用户分类	召开多次头脑风暴或集体会议明确所有的用户分类。
不准确的产品开发计划	召开多次集体会议明确所有的产品开发计划书。

2.6 产品风险

风险	解决方案
开发额外的不需要的功能(镀金),延长了计划进度	使用迭代开发，将开发过程分为多个阶段，每个阶段开始之前联系用户，让用户参与需求分析，结合用户的想法进行修改，删除用户认为无用的功能
要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作	在做系统的总体设计方案时，先把好相关产品的选型关，确保网络、主机、系统软件与应用软件之间不要存在较大的技术兼容性问题，确定相关设备的技术参数和配置要求。
在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题
开发一种全新的模块将比预期花费更长的时间	在项目开发早期，建立系统的架构，对系统所需要应用的技术做深度探索。让小组里编程能力较强的组员优先解决关键技术难题，编程能力较差的组员负责较基础的功能编写，必要时刻利用网络解决问题

2.7 设计和实现风险

风险	解决方案
设计质量低下,导致重复设计	使用迭代开发，将开发过程分为多个阶段，每个阶段完成之后联系用户，让用户参与测试，结合用户的使用感想进行阶段性修改，将每个阶段的开发任务分给不同的组员，该开发阶段中，开发人员专注开发，未分到开发任务的组员进行测试和报告的撰写，同时对代码进行监督，若代码质量低则及时反馈，保证每个人负责的板块不同但对他人写的模块都有所了解
代码和库的质量低下,导致需要进行额外的测试,修正错误,或重新制作
分别开发的模块无法有效集成,需要重新设计或制作
一些必要的功能无法使用现有的代码和库来实现,开发人员必须使用新的库或者自行开发新的功能	在项目开发早期，建立系统的架构，对系统所需要应用的技术做深度探索。让小组里编程能力较强的组员优先解决关键技术难题，编程能力较差的组员负责较基础的功能编写，必要时刻利用网络解决问题，若实在无法解决则求助老师

转载于:https://www.cnblogs.com/tyt-/p/10744191.html

你可能感兴趣的文章

1、 文档目的

2、 风险