综合项目风险评估分析报告范文

项目风险评定汇报本文档范围和目标

本文关键针对软件开发包含到风险，包含在软件开发周期过程中可能出现风险和软件实施过程中外部环境改变可能引发风险等进行评定。在文中对所提到风险全部一一做了具体分析，并提出了对应风险回避方法。

因为风险是在项目开始以后才开始对项目标开提议负面影响，所以风险分析不足，或是风险回避方法不得力，全部很有可能造成软件开发失败。风险分析是在事前一个估量，凭借一定技术手段和丰富经验，基础能够对项目标风险做出比较正确估量，经过慎重考虑提出可行风险回避方法，是避免损失关键步骤。

关键风险综述

任何软件开发，其关键风险均来自于两个方面，一是软件管理，二是软件体系结构。软件产品开发是工程技术和个人创作有机结合。软件开发是人集体智慧根据工程化思想进行发挥过程。软件管理是确保软件开发工程化手段。软件体系结构合理程度是取决于集体智慧发挥程度和经验利用。

软件管理将影响到软件下列原因：

软件是否能够按工期要求完成：软件工期常常是制约软件质量关键原因。很多情况下，软件开发商在工期压力下，放弃文档书写，组织，结果在工程晚期，大量需要文档进行协调工作时，致使软件进度越来越慢。软件开发不一样于其它工程，在不一样工程阶段，需要人员不一样，需要配合方面也不一样，全部这些全部需要行之有效软件管理确保。

软件需求调研是否深入透彻：软件需求是确保软件正确反应用户对软件使用关键文档，探讨软件需求是软件开提议始点，但软件需求却会贯穿整个软件开发过程，软件管理需要对软件需求改变进行控制和管理，首先确保软件需求改变不至于造成软件工程一改再改而无法按期完成；同时又要确保开发软件能够为用户所接收。软件管理需要控制软件每个阶段进行成度，不能过细造成时间浪费，也不能过粗，造成软件缺点。

软件实现技术手段是否能够同时满足性能要求：软件结构需要对软件结构过程中使用多种技术进行评定。软件结构技术通常是这么：最成熟技术，往往不能表现最好软件性能；优异技术，往往人员对其熟悉程度不够，对其中隐含缺点不够明了。软件管理在制订软件开发计划和定义里程碑时必需考虑这些原因，并做出合理权衡决议。

软件质量体系是否能够被有效地确保：任何软件管理忽略软件质量监督步骤全部将对软件生产组成巨大风险。而制订卓有成效软件质量监督体系，是任何软件开发组织必不可少。软件质量确保体系是软件开发成为可控制过程基础，也是开发商和用户进行交流基础和依据。

软件体系结构影响到软件以下质量原因：

软件可伸缩性：是指软件在不进行修改情况下适应不一样工作环境能力。因为硬件飞速发展和软件开发周期较长矛盾，软件升级需要显得很迫切。假如软件升级和移植很困难，软件生命期肯定很短，使得化费巨大人力物力开发出软件系统只能在低性能硬件或网络上运行，甚至被废弃不用，造成巨大浪费。

软件可维护性：软件维护也是肯定事情，为了确保软件较长使用寿命，软件就必需适应不停业务需求改变，依据业务需求改变对软件进行修改。修改成本和周期全部直接和软件体系结构相关。一个好软件体系结构能够尽可能地将系统改变放在系统配置上，即软件代码无需修改，仅仅是在系统提供配置文件中进行合适修改，然后软件重新加载进入运行状态，就完成了系统部分功效和性能要求改变。对于重大改动，需要打开源代码进行修改，也仅仅是先继承原先代码，然后用新功效接替原先调用接口，这么将把软件改动量减小到最低。

软件易用性：软件易用性是影响软件是否被用户接收关键之关键原因。在软件产品中，设计复杂，功效强大而完备，但因为操作繁复而被搁置者屡见不鲜。造成关键原因在于缺乏软件开发中软件体系结构宏观把握能力。其次，缺乏有效手段进行软件需求确实定和对潜在需求挖掘。

项目管理风险

软件项目管理风险来自于软件项目本身特点：

软件产品不可见：开发进展和软件质量是否符合要求难于度量，从而使软件管理难于把握。

软件生产过程不存在绝对正确过程形式：能够肯定是不一样软件开发项目应该采取不一样或说是有针对性软件开发过程，而真正适宜软件开发过程是在软件项目标开发完成才能明了。所以项目开发之初只能依据项目标特点和开发经验进行选择，并在开发过程中不停调整。

大型软件项目往往是"一次性"。以往经验能够被借鉴地方不多。回避和控制软件管理风险唯一措施就是设置监督制度，项目开发中任何较大决定全部必需相关键技术步骤甚至是由用户参与进行。在该项目中项目监督由项目开发中质量监督组来实施。

通常参与软件开发人员（包含管理者和技术人员）和其责任进行分析以下：

参与者

项目经理1人

关键职责：进行全局把握，侧重于项目标商务方面，充当项目组同用户正式交流接口步骤。

项目责任人1人

关键职责：制订项目开发计划和开发策略，参与项目关键系统分析设计，同时努力确保开发计划按时完成和开发策略真正落实落实。

领域教授1或2人

关键职责：在软件分析阶段帮助分析人员界定系统实现边界和实现功效，对特定检测点进行算法审核，同时对测试策略和软件操作界面提出参考意见。

质量监督组1或2人

关键职责：编制软件质量控制计划，并负责落实；控制必需文档生产，经过文档，监督项目实施过程中软件质量，并产生软件质量汇报，提请项目经理和项目责任人审阅；对于项目中出现质量问题，主持召开质量复审会议。

系统分析员1或2人

关键职责：协同项目责任人进行软件系统分析和设计工作，书写软件需求分析和系统设计相关文档。在软件实现阶段进行测试策略编制和对性能测试指导。

程序员2或3人

关键职责：帮助分析人员进行具体设计，和软件系统代码实现，并进行合适白盒测试。

测试员2或3人

关键职责：已经实现软件组件、构件或系统进行正确性验证测试，整合后系统性能测试等。书写测试汇报和测试统计汇报提请质量监督组复审。

技术支持2或3人

关键职责：协同系统分析人员听取用户需求，对需求分析进行参考性复审。协同测试人员进行测试，书写操作手册和在线帮助，在项目交付用户以后进行跟踪服务。

文档组1或2人

关键职责：对各部门产生文档进行格式规范、版本编号和控制、存档文件检索；帮助质量监督组进行软件质量监督。经过合适人员配置和职责划分，能有效降低软件开发在后期失控可能性，和软件对关键人员依靠性。

软件技术风险

本系统拟订采取两个重大软件技术是面向对象构件和基于微软COM组件技术。组件和构件技术全部是为了提升软件可靠性和软件可扩展性而采取技术手段。从技术成熟度上说不存在风险，但为了实现良好软件构架和稳定组件，和传统开发方法比较，有相当多额外工作需要做，这会给项目工期带来较大风险。

回避和控制这部分风险措施是在项目进行过程不停对该阶段进行风险估量和指定有效里程碑。同时采取"范例"方法提升开发人员构件组件分析识别能力，适时调整构件组件数量和粒度。

软件过程风险

软件需求阶段风险

软件开发是以用户需求开始，在大多数情况下，用户需求要靠软件开发方诱导才能确保需求完整，再以书面形式形成《用户需求》这一关键文档。需求分析更多是开发方确定需求可行性和一致性过程，在此阶段需要和用户进行广泛交流和确定。需求和需求分析任何疏漏造成损失会在软件系统后续阶段被一级一级地放大，所以本阶段风险最大。

设计阶段风险

设计关键目标在于软件功效正确反应了需求。可见需求不完整和对需求分析不完整和错误，在设计阶段被成倍地放大。设计阶段关键任务是完成系统体系结构定义，使之能够完成需求阶段即定目标；其次也是检验需求一致性和需求分析完整性和正确性。

设计本身风险关键来自于系统分析人员。分析人员在设计系统结构时过于定制，系统可扩展性较弱，会给后期维护带来巨大负担，和维护成本激增。对用户来说系统使用百分比会有显著折扣，甚至造成软件寿命过短。反之，软件结构过于灵活和通用，肯定引发软件实现难度增加，系统复杂度会上升，这又会在实现和测试阶段带来风险，系统稳定性也会受到影响。从另一个角度上看，业务规则改变，或说用户需求和未来软件运行环境改变全部是肯定情况，现在软件设计所谓"通用性"是否就能很好适应未来需求和运行环境改变，是需要认真折衷。这种折中也蕴涵着很大风险。

设计阶段蕴涵另一个风险来自于设计文档。文档不健全不仅会造成实现阶段困难，更会在后期测试和维护造成灾难性后果，比如根本无法对软件系统进行版本升级，甚至是发觉简单错误全部无从更正。

实现阶段引入风险

软件实现从某种意义上讲是软件代码生产。原代码本身也是文档一部分，同时它又是未来运行于计算机系统之上实体。源代码书写规范性，可读性是该阶段关键风险起源。规范代码生产会把属于程序员本身个性风格成份引入代码百分比降到最低程度，从而减小了系统整合风险。

维护阶段风险

软件维护包含两个关键维护阶段，一个是软件生产完成到软件试运行阶段维护，这个阶段是一个实环境测试性维护，其关键目标是发觉在测试环境中不能或未发觉问题；另一个阶段是当软件运行不再能适应用户业务需求或是用户运行环境（包含硬件平台，软件环境等）时进行软件维护，具体可能是软件版本升级或软件移植等。

从软件工程角度看，软件维护费用约占总费用55%~70%，系统越大，该费用越高。对系统可维护性轻视是大型软件系统最大风险。在软件漫长运行期内，业务规则肯定会不停发展，科学处理此问题做法是不停对软件系统进行版本升级，在确保可维护性前提下逐步扩展系统。

在软件系统运行期间，关键风险源自于技术支持体系无效运转。科学方法是有一支用户支持队伍不停搜集运行中发觉问题，并将处理问题方法传授给软件系统全部使用者。

项目风险表

风险评定表中所提到风险是通常项目在开发过程中全部客观存在，表中所列出风险系数是指在不对风险进行深入分析和有效规避情况下，该风险项发生概率。比如软件产品设计目标是运行十年，体系结构不合理风险是40%含义是，假如不对系统进行深