软件项目风险管控.doc

推介导读：
此论文从需求调研、开发、实施以及项目收尾四个项目阶段，列举了11种典型的常见风险，并给出了这些风险的详细和切实可行的风险规避措施。这些风险和措施实用、实在，值得做为公司项目管理财富库进行收藏，值得各项目组借鉴。

软件项目风险管控
1. 什么是软件项目风险
软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目目标不能实现。如果对项目进行风险管理，就可以最大限度的减少风险的发生。
2. 项目风险及应对措施
软件项目的生命周期可以分为四个阶段，即需求调研阶段、开发阶段、实施阶段、收尾阶段，软件开发过程可分为：需求分析、设计、编码、测试等几个过程，在软件项目的每个阶段、每个过程都可能存在风险。下面结合项目谈谈各阶段碰到的风险。
2.1. 需求调研阶段
1． 风险描述：
调研涉众没有足够的时间参与调研活动，严重影响调研进度与调研质量。
应对措施：
Ø 开始调研时，召集公司的高层领导、各部门主管及参与调研的关键涉众召开调研启动会，让所有涉众都重视本次调研活动，努力配合调研工作。在调研启动会上明确调研涉众的职责；
Ø 在制定调研计划时，应事前与相关涉众做好沟通工作，努力减少调研计划与日常工作安排的冲突；
Ø 相关人员通过移交日常工作等办法，有效保证相关涉众的调研时间；
Ø 调研人员设计调研提纲时，要有针对性，尽量努力提高调研效率。
2． 风险描述：
调研成果不能真实和完整地体现管理层意图与企业经营管理需要。
应对措施：
Ø 通过客户方的多方协调，让管理层要重视调研人员的访谈，客观而真实地回答访谈问题；
Ø 管理层调研提纲在设计时，不仅要做到有针对性，而且要有全面性；
Ø 调研人员在访谈管理层，要善于挖掘与总结管理层的管理意图与经营思路；
Ø 管理层的意图应宣达到所有涉众，努力做到在繁多的需求中，把握住管理思路的主线。
3． 风险描述：
在某些需求议题上，不同部门、不同单位可能会有不同的理解与要求，且可能会各自坚持自己的意见，无法达成共识。
应对措施：
Ø 通过管理层宣传与教育，让相关涉众认识到业务流程标准化的重要性；
Ø 由总部成立业务专家小组，在出现需求不一致，提出权威的解决方案；
Ø 调研人员凭借自身的流程分析能力，尽量定义出能兼容不同需求的解决方案。
Ø 对确实无法达成共识的需求，可以采用暂时搁置争议办法，以保证进度。
4． 风险描述：
调研成果偏离调研涉众的需求
应对措施：
Ø 调研时认真聆听调研涉众的需求，然后理解及复述调研的需求；
Ø 调研完成后，在当天整理出涉众备忘录、调研涉众的交付物清单，梳理并绘制流程图；
Ø 第二天安排足够的时间，与调研涉众核对涉众备忘录、流程图、交付物清单，并得到调研涉众的书面确认；
Ø 每家分公司的所有调研成果最终都要有分公司领导的书面签字确认。
2.2. 开发阶段
1． 风险描述：
错误理解需求分析，导致开发成果与用户需求偏离。
应对措施：
Ø 准确规范的文字表达模式；
Ø 系统分析师与开发人员保持密切沟通，必要时召开会议向全体开发小组成员介绍需求的详细情况
Ø 功能开发完后，系统分析师检查功能实现情况及效果；
2． 风险描述：
项目周期短导致开发周期短，需要把SQL翻译为ORACLE，而且要统一平台整合船代与货代系统，开发任务艰巨，可能导致开发无法如期开发完成的风险。
应对措施：
Ø 增加项目组熟练开发人员；
Ø 分析、设计、开发、测试迭代进行；
Ø 在客户方搭建测试环境，开发完成部分功能后，发布到客户方测试环境，让关键用户一起验证，及时纠正偏离的需求。
2.3. 实施阶段
1． 风险描述：
基础数据收集不完整、不及时，导致系统UAT效果不好。
应对措施：
Ø 尽早整理所有需要收集的基础信息表，发给各公司系统负责人，并告知收集的期限，收集的期限必须要预留缓冲时间。
Ø 收集到基础信息表要必须在UAT开始前导入系统的UAT环境。
Ø 基础数据维护是一个漫长的过程，建议UAT的基础数据按正确的数据进行维护，上线时直接导入正式环境。
2． 风险描述：
UAT效果不好，导致无法如期上线。
应对措施：
Ø 与公司领导、各业务部门主管了解公司的业务线，制定UAT计划时必须涵盖公司的所有业务线；
Ø 与UAT用户共同制定各业务线的录入数据量，每天或者每周统计数据录入情况，汇报相关项目干系人。统计清单中必须有计划录入数据量、实际录入数据量、完成百分比情况；
Ø 若录入数据量比计划数据量偏差比较大时，必须及时召开例会并让公司领导一起参与会议。
Ø UAT时，必须让关键用户清楚知道整个操作流程及功能点，必须要有功能清单。
3． 风险描述：
UAT后上线还是有一大堆问题，上线效果非常差，没达到用户的预期。
应对措施：
Ø UAT后建议安排系统并行，根据各业务线的情况制定并行计划。例如：有的业务线数据量比较少可以采取完全并行的模式，有的业务线数据量比较大可以采取并行50%的方式；
Ø 让所有的最终用户参与系统的并行；
Ø 并行阶段每天或者每周统计数据录入情况，汇报相关项目干系人。统计清单中必须有计划录入数据量、实际录入数据量、完成百分比情况；
4． 风险描述：
UAT阶段都没什么问题，上线时因某个功能原因推迟上线。
应对措施：
Ø 项目启动时，严格制定上线标准；
Ø UAT阶段要有详细的功能清单、EDI清单、打印套版、接口清单，让关键用户知道试用的内容；
Ø 在UAT期间，必须要让关键用户对这些清单进行试用，并规定问题反馈的期限；
Ø 上线一周前收集关键用户对这些清单的签字确认，至少预留一周的缓冲时间。
2.4. 收尾阶段
1． 风险描述：
系统的验收是整个项目过程中最难的里程碑点，系统不可能做到完全没有问题，客户可以找一些理由迟迟不验收系统。
应对措施：
Ø 签订商务合同的时候，规定验收的期限，例如：上线后多长时间完成验收工作；
Ø 验收标准正常情况下是按需求规格说明书及合同规定的交付物进行验收，但是项目周期紧，开始写的需求规格说明书到了系统验收阶段往往偏离比较大。双方项目经理及相关领导讨论制定系统需求收集期限，并对需求进行划分，划分出合同范围内验收前解决的需求清单，合同范围外验收前解决的需求清单。针对这些需求进行集中处理。
Ø 双方对合同交付物的理解可能会存在一定的偏差，也需要双方项目经理及相关领导进行详细的沟通，确定验收时的不违背合同的交付物清单，项目组集中收集这些信息。
3. 总结
软件项目风险贯穿整个项目的始终，风险无处不在，风险无时不有，风险并不可怕，可怕的是没识别风险，可怕的是没有风险管控。

Welcome To
Download !!!

欢迎您的下载，资料仅供参考！

精品资料