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