下面是小编为大家整理的项目风险管理知识：风险评估报告（全文完整）,供大家参考。
项目风险管理知识：风险评估报告
引言
本文档的范围和目的
本文主要评估软件开发所涉及的风险，包括软件开发周期内可能发生的风险和软件实施过程中外部环境变化可能导致的风险。本文对上述风险进行了详细分析，并提出了相应的风险规避措施。
由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险 回避措施，是避免损失的重要环节。
主要风险综述
任何软件的开发，其主要风险均来自于两个方面，一是软件管理，二是软件体系结构。软件产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想进行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用。
软件管理将影响到软件的下列因素：
软件能否按时限完成: : 软件的时限往往是制约软件质量的主要因素。很多情况下，在工期的压力下，软件开发人员放
弃了文档的编写和组织。这样一来，在 项目的后期，需要协调大量的文档，导致软件进度越来越慢。软件开发不同于其他项目。在不同的工程阶段，需要不同的人，需要协调不同的方面，这些都需要有效的软件管理的保证。
软件需求的调研是否深入透彻：软件的需求是确保软件正确反映用户的对软件使用的重要的文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成；同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行 的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。
软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。
软件质量体系是否能够被有效地保证：任何软件管理忽略软件质量监督环节都将对软件的生产构成巨大的风险。而制定卓有成效的软件质量监督体系， 是任何软件开发组织必不可少的。软件质量保证体系是软件开发成为可控制过程的基础，也是开发商和用户进行交流的基础和依据。
软件体系结构影响到软件的如下质量因素：
软件的可伸缩性：是指软件在不进行修改的情况下适应不同的工作环境的能力。由于硬件的飞速发展和软件开发周期较长的矛盾，软件升级的需要显得非常迫切。如果软件的
升级和移植非常困难，软件的生命期必定很短，使得化费巨大人力物力开发出的软件系统只能在低性能的硬件或网络上运行，甚至被废弃不用，造成巨大的浪费。
软件的可维护性: : 软件维护也是一件不可避免的事 情。为了保证软件的长寿命，软件必须适应业务需求的不断变化，并根据业务需求的变化对软件进行修改。修改的成本和周期与软件架构直接相关。好的软件架构能够将系统的变化尽可能的放在系统的配置上，即不需要修改软件代码，只需要在系统提供的配置文件中做适当的修改，然后重新加载软件进入运行状态，从而完成系统的部分功能和性能需求的变化。对于重大的改动，如果需要打开源代码进行修改，只需要先继承原代码，然后用新的函数替换原来的调用接口，这样可以最大限度的减少软件改动量。
软件易用性：软件的易用性是影响软件是否被用户接受的关键之 关键因素。在软件产品中，设计复杂，功能强大而完备，但因为操作繁复而被搁置者屡见不鲜。造成的主要原因在于缺乏软件开发中软件体系结构的宏观把握能力。另一方面，缺乏有效的手段进行软件需求的确定和对潜在需求的挖掘。
项目管理的风险
软件项目管理的风险来自于软件项目自身的特点：
无形产品: : 难以度量开发的进度，软件的质量是否符合要求，使得软件的管理难以把握。
软件生产过程中不存在绝对正确的过程形式: : 不同的软件开发项目应该采用不同的或有针对性的软件开发过程是确定的，真正合适的软件开发过程只有在软件项目 开发完成后才
能知道。所以在项目开发之初，只能根据项目的特点和开发经验进行选择，并在开发过程中不断调整。
大型软件项目往往是" " 一次性" " 的。以往的经验可以被借鉴的地方不多。回避和控制软件管理风险的唯一办法就是设立监督制度，项目开发中任何较大的决定都必须有主要技术环节甚至是由用户参与进行的。在该项目中项目监督由项目开发中的质量监督组来实施。
一般参与软件开发的人员（包括管理者和技术人员）和其责任进行分析如下：
参与者
项目经理 1 1 人
职责: : 把握全局，专注于项目的业务方面，作为项目团队与客户正 式沟通的接口纽带。
项目负责人 1 1 人
主要职责：制定项目开发计划和开发策略，参与项目核心系统的分析设计，同时努力保证开发
计划按时完成，发展战略真正落实。
领域专家 1 1 或 或 2 2 人
主要职责：在软件分析阶段帮助分析人员界定系统实现边界和实现的功能，对特定检测点进行
算法审核，同时对测试策略和软件操作界面提出建议。
质量监督组 1 1 或 或 2 2 人
职责: : 编制软件质量控制计划并负责实施；控制必要文档的制作，通过文档监督项目实施过程中的软件质量，制作软件质量报告供项目经理和项目负责人审核；针对工程中的质量问题，主持质量评审会。
系统分析员 1 1 或 或 2 2 人
主要职责：协同项目负责人进行软件系统的分析和设计工作，书写软件需求分析和系统设计相关文档。在软件实现阶段进行测试策略的编制和对性能测试的指导。
程序员 2 2 或 或 3 3 人
主要职责：协助分析人员进行详细设计，和软件系统的代码实现，并进行适当的白盒测试。
测试员 2 2 或 或 3 3 人
主要职责: : 验证和测试已实现的 软件组件、部件或系统的正确性，测试集成系统的性能。撰写测试报告和统计报告，并提交给质量监督小组审查。
技术支持 2 2 或 或 3 3 人
职责: : 配合系统分析师听取用户需求，审核需求分析以供参考。配合测试人员进行测试，编写操作手册和在线帮助，提供项目交付用户后的后续服务。
文档组 1 1 或 或 2 2 人
主要职责: : 各部门制作的文件的格式规范、版本号及控制、归档文件检索；协助质量监督团队进行软件质量监督。适当的人员配备和职责分工，可以有效降低软件开发后期失控的可能性，降低软件对关键人员的依赖。
软件技术风险
本系统拟 订采用的两个重大的软件技术是面向对象的构件和基于微软的 M COM 组件技术。组件和构件技术都是为了提高软件的可靠性和软件的可扩展性而采用的技术手段。从技术成熟度上说不存在风险，但为了实现良好的软件构架和稳定的组件，与传统开发方法比较，有相当的多的额外工作需要做，这会给项目工期带来较大的风险。
回避和控制这部分风险的办法是在项目进行的过程不断的对该阶段进行风险估计和指定有效的里程碑。同时采用" " 范例" " 方式提高开发人员的构件组件的分析识别能力，适时调整构件组件的数量和粒度。
软件过程风险
软件需求阶段的风险
软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方诱导才能保证需求的完整，再以书面的形式形成《用户需求》这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级一级地放大，因此本阶段的风险最大。
设计阶段的风险
设计的主要目的在于软件的功能正确的反映了需求。可见需求的不完整和对需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之能够完
成需求阶段的即定目标；另一方面也是检验需求的一致性和需求分析的完整性和正确性。
设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。对用户来说系统的使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险，系统的稳定性也会受到影响。从另一个角度上看，业务规则的变化，或说用户需求和将来软件运行环境的变化都是必然的情况，目前软件设计的所谓" " 通用性" " 是否就能很好的适应将来需求和运行环境的的变化，是需要认真折衷的。这种折中也蕴涵着很大的风险。
设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现的简单错误都无从更正。
实现阶段引入的风险
从某种意义上说，软件的实现就是软件代码的生产。原代码本身也是文档的一部分，也是将来在计算机系统上运行的实体。源代码的标准化和可读性是这个阶段的主要风险源。标准化的代码生产会将属于程序员自身个性风格的元素引入代码的比例降到最低，从而降低系统集成的风险。
维护阶段的风险
软件维护包括两个主要的维护阶段，一个是从软件生产结束到试运行阶段的维护，这是一种在真实环境中可测试的维护，其主要目的是发现测试环境中不能或不能发现的问题；另一个阶段是当软件的运行已经不能满足用户的业务需求或用户的运行环境( ( 包括硬件平台、软件环境等) ) 时的软件维护。) ) ，可能是软件版本升级或者软件移植等。
从软件工程的角度看，软件维护费用约占总费用的55%~70% ，系统越大，该费用越高。
对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，
科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。
在软件系统运行过程中，主要风险来自技术支持系统的无效运行。科学的方法是让一个客户支持团队不断收集运营中发现的问题，并把解决方案教给软件系统的所有用户。
项目风险表
风险评估表中所提到的风险是一般项目在开发过程中都客观存在的，表中所列出的风险系数是指在不对风险进行深入的分析和有效的规避的情况下，该风险项发生的概率。
比如软件产品的设计目标是运行十年，体系结构不合理的风险是 是 40% 的含义是，如果不对系统进行深入的分析，未采用最合理的软件技术进行设计，则生产出一个不具备可扩展性的软件系统的概率是 40% 。由于客户公司是仍将不断发展的，在十年内，该软件系统都能满足公司运营要求的可能性极低。由此而可能产生的灾难性后果是公司在业务发展的时候，必须重新开发新系统。
向客户提供风险评估是符合国际惯例的常规操作。一方面让客户对潜在风险有更充分的了解，表明公司诚信的态度；另一方面也用来鞭策和激励所有开发者严格执行开发标准，共同监督项目 开发过程，努力规避风险。
推荐访问:项目风险管理知识：风险评估报告 管理知识 评估报告 完整