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