2023年项目研究风险评估报告汇聚优秀4篇

【导读预览】此篇优秀范文“2023年项目研究风险评估报告汇聚优秀4篇”由阿拉题库网友为您整理分享，以供您参考学习之用，希望此篇资料对您有所帮助，喜欢就复制下载支持吧！

项目研究风险评估报告【第一篇】

本文档的范围和目的

本文主要针对软件开发涉及到的风险，包括在软件开发周期过程中可能出现的风险以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了详细的分析，并提出了相应的风险回避措施。

由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。

主要风险综述

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

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

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

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

软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。

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

软件体系结构影响到软件的如下质量因素：

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

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

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

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

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

软件的生产过程不存在绝对正确的过程形式：可以肯定的是不同的软件开发项目应当采用不同的或者说是有针对性的软件开发过程，而真正合适的软件开发过程是在软件项目的开发完成才能明了的。因此项目开发之初只能根据项目的特点和开发经验进行选择，并在开发过程中不断的调整。

大型软件项目往往是"一次性"的。以往的经验可以被借鉴的地方不多。回避和控制软件管理风险的唯一办法就是设立监督制度，项目开发中任何较大的决定都必须有主要技术环节甚至是由用户参与进行的。在该项目中项目监督由项目开发中的质量监督组来实施。

参与者

项目经理1人

主要职责：进行全局把握，侧重于项目的商务方面，充当项目组同客户正式交流的接口环节。

项目负责人1人

主要职责：制定项目开发计划和开发策略，参与项目核心系统的分析设计，同时努力保证开发计划的按时完成和开发策略的真正贯彻落实。

领域专家1或2人

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

质量监督组1或2人

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

系统分析员1或2人

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

程序员2或3人

主要职责：协助分析人员进行详细设计，和软件系统的代码实现，并进行适当的白盒测试。

测试员2或3人

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

技术支持2或3人

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

文档组1或2人

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

软件技术风险

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

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

软件过程风险

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

设计阶段的风险

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

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

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

实现阶段引入的风险

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

维护阶段的风险

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

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

在软件系统运营期间，主要的风险源自于技术支持体系的无效运转。科学的方法是有一支客户支持队伍不断收集运行中发现的问题，并将解决问题的方法传授给软件系统的所有使用者。

风险评估表中所提到的风险是一般项目在开发过程中都客观存在的，表中所列出的风险系数是指在不对风险进行深入的分析和有效的规避的情况下，该风险项发生的概率。比如软件产品的设计目标是运行十年，体系结构不合理的风险是40%的含义是，如果不对系统进行深入的分析，未采用最合理的软件技术进行设计，则生产出一个不具备可扩展性的软件系统的概率是40%。由于客户公司是仍将不断发展的，在十年内，该软件系统都能满足公司运营要求的可能性极低。由此而可能产生的灾难性后果是公司在业务发展的时候，必须重新开发新系统。

向客户提供风险评估，是按照国际惯例进行的例行操作，一方面让客户对潜在的风险有更充分的了解，表明公司诚信 为本的态度，另一方面也用以鞭策和激励全体开发人员严格执行开发标准，共同监督项目开发过程，努力避免风险的发生。

项目研究风险评估报告【第二篇】

发光二极管(lightemitting diode，led)，是一种半导体组件。初时多用作为指示灯、显示发光二极管板等；随着来沃1ed照明白光led的出现，也被用作照明。

led 被称为第四代照明光源或绿色光源，具有节能、环保、寿命长、体积小等特点，广泛应用于各种指示、显示、装饰、背光源、普通照明和城市夜景等领域。根据使用功能的不同，可以将其划分为信息显示、信号灯、车用灯具、液晶屏背光源、通用照明五大类。

在政策护航、销量提升等因素的推动下，led成为近期资本市场的投资热点之一，其中新海宜、福晶科技等表现抢眼。由于第四季度是led照明、电视等产品消费的高峰期，上游零组件产业销量也会出现周期性的攀升。随着10月1日我国禁售和进口60瓦及以上白炽灯政策落实，我国淘汰白炽灯路线图已经开启，led照明渗透率将不断提升。业内人士表示，仅白炽灯替代市场每年就将新增120亿只以上灯源需求。

led产品主要应用于背光源、彩屏、室内照明三大领域。由于背光源是现阶段led最大的应用市场，近几年驱动led产业高速增长。未来在产品价格下降以及新一轮全球禁售白炽灯高潮兴起等因素的影响下，室内照明将替代背光源成为未来led增长最快的细分领域。此外，近年来在小间距显示屏等产品升级因素驱动下，led产品增速也不断提升，呈现稳健增长的趋势。综合来看，未来led总需求将呈现持续增长，相关公司具备中长期投资价值。

目前我国正在逐步成为全球led产业基地。统计数据显示，20xx年我国照明行业总产值4800亿元。其中包括350亿美金的出口市场和20xx多亿元的国内市场。相较于20xx多亿元的增量市场，业内人士认为改革开放30年形成的照明存量市场将存在数万亿元的市场空间。预计led照明未来3~5年将会形成行业产值高峰，将保持100%的年复合增速，行业总产值有望达到万亿元。

此外，海外新兴市场正为国内led企业带来更大的机会。今年上半年我国led照明产品出口金额约为亿美元。其中金砖国家约亿美元，同比增幅高达350%。海外新兴市场快速增长将会持续利好国内led厂商。

项目可行性研究报告是企业从事建设项目投资活动之前，由可行性研究主体（一般是专业咨询机构）对市场、收益、技术、法规等项目影响因素进行具体调查、研究、分析，确定有利和不利的因素，分析项目必要性、项目是否可行，评估项目经济效益和社会效益，为项目投资主体提供决策支持意见或申请项目主管部门批复的文件。

—— 用于报送发改委立项、核准或备案

—— 用于申请土地

—— 用于申请国家专项资金

—— 用于申请政府补贴

—— 用于融资、银行贷款

—— 用于对外招商合作

—— 用于上市募投

—— 用于园区评价定级

—— 用于企业工程建设指导

—— 用于企业节能审查

—— 用于环保部门对项目进行环境评价

—— 用于安监部门对项目进行安全审查

项目研究风险评估报告【第三篇】

对于风险评估来说，其三个关键要素是信息资产、弱点/脆弱性以及威胁。每个要素有其各自的属性，信息资产的属性是资产价值，弱点的属性是弱点被威胁利用后对资产带来的影响的严重程度，威胁的属性是威胁发生的可能性。信息安全风险评估的具体工作流程如图1所示。

一、风险评估的准备

2．确定风险评估的目的，为风险评估的实施提供导向；

3．建立适当的组织结构；

5．获得最高管理者对风险评估策划的批准。

二、风险评估的实施

组织应根据策划的结果，由评估的人员按照相应的职责和程序进行资产评估、威胁评估、脆弱性评估。在考虑已有安全措施的情况下，利用适当的方法与工具确定威胁利用资产脆弱性发生安全事件的可能性，并结合资产的安全属性受到破坏后的影响来得出资产的安全风险。

三、风险计算

风险计算的模型如图2所示。

我们以下述函数进行表示：

r= f(a,v,t)=f(ia,l(va,t))

其中：r表示风险；a表示资产；v表示脆弱性；t表示威胁； ia表示资产发生安全事件后对组织业务的影响(也称为资产的重要程度);va表示某一资产本身的脆弱性，l表示威胁利用资产的脆弱性造成安全事件发生的可能性。

具体而言分为以下几个步骤：

1．首先对资产的弱点进行排序；

2．针对每一个弱点，确定可能利用此弱点造成安全事件的威胁的类型；

3．给确定的威胁赋值；

4．将威胁值与脆弱点值相乘，得出安全事件发生的可能性；即：

安全事件发生可能性=l（威胁可能性，脆弱点严重性）；

5．根据资产的重要程度以及安全事件发生的可能性计算风险值，即：

风险值=r（资产重要程度，安全事件发生的可能性）。

四、风险识别

风险识别包括三个部分：分析风险来源；识别区域风险；风险关联分析。

1．分析风险来源

经过资产、威胁、脆弱性的计算后形成一个风险列表，需要对该列表的风险进行分类，并在分类的基础上进行风险合并。在对风险进行分类合并时，首先需要考虑风险所发生的位置，然后考虑风险的来源。风险的来源可以从威胁、脆弱性和安全管理三个方面进行。

风险发生的位置可以从资产所在的安全域或从信息安全发生的层次进行划分。资产所在的安全域指具有相同安全属性的某一物理区域或逻辑区域，该区域和其他安全区域具有明显的边界；信息安全发生的层次指物理层安全、网络层安全、操作系统层安全、应用层安全、数据层安全。风险的来源从威胁角度进行合并，可以从威胁的来源，发生的途经，影响的大小角度进行划分整理。风险的来源从脆弱性角度进行合并，从大的方面有两类，一类是it技术类脆弱性，另一类是管理类脆弱性。安全管理类脆弱性可以从设计、开发、验收、运行、维护、人员、业务持续性管理等方面进行分析。

2．识别区域风险

分类合并后的风险需要再次进行人工判断，通过这种判断可以发现被分析的安全域的主要威胁、主要影响和发生的可能性。这种经过判断的风险需要进行单独说明，使最后形成的风险具有更明确的意义。

3．风险关联分析

经过风险识别后的风险是系统中的主要风险，对于复杂系统，还需要考虑多个风险之间的相互关系。这种主要风险之间的潜在相互影响包括：不同安全区域风险的相互影响，不同业务风险之间的影响，不同系统之间风险的影响分析。经过风险关联分析后还需要重新修正风险识别列表。（未完待续）

判定风险结果

确定风险数值的大小不是组织风险评估的最终目的。重要的是明确不同威胁对资产所产生的风险的相对值，即，要确定不同风险的优先次序或等级。对于风险级别高的资产应被优先分配资源进行保护。组织可以采用按照风险数值排序的方法，也可以采用区间划分的方法将风险划分为不同的优先等级，这包括将可接受风险与不可接受风险进行划分，接受与不可接受的界限应当考虑风险控制成本与风险（机会损失成本）的平衡。风险的等级应得到组织管理层的评审并批准。

组织在对风险等级进行划分后，应考虑法律法规（包括客户及相关方）的要求、组织自身的发展要求。根据风险评估的结果确定安全水平，对不可接受的风险选择适当的处理方式及控制措施，并形成风险处理计划。风险处理的方式包括：回避风险、降低风险（降低发生的可能性或减小后果）、转移风险、接受风险。控制措施的选择应兼顾管理与技术，具体地说，针对各类风险应根据组织的实际情况考虑以下十个方面的控制：安全方针、组织安全、资产的分类与控制、人员安全、物理与环境安全、通信与运作管理、访问控制、系统的开发与维护、业务持续性管理、符合性。在风险处理方式及控制措施的选择上，组织应考虑发展战略、企业文化、人员素质，并特别关注成本与风险的平衡，处理安全风险以满足法律法规及相关方的要求。管理性与技术性的措施均可以降低风险，但在控制措施的选择上应遵循上述原则。单纯选择某种控制措施可能会降低成本，但也可能引入新的风险，因此应注意预防性控制措施与检查性控制措施之间的关系。在预防性控制不足以确保风险得到降低的情况下应追加检查性控制措施。通常应该考虑联合各种选择。

对于不可接受范围内的风险，应在选择了适当的控制措施后，对残余风险进行评价，判定风险是否已经降低到可接受的水平，为风险管理提供输入。残余风险的评价可以依据组织风险评估的准则进行，选择的控制措施和已有的控制措施应当考虑降低威胁发生的可能性。某些风险可能在选择了适当的控制措施后仍处于不可接受的风险范围内，应由管理层依据风险接受的原则，考虑是否接受此类风险或增加控制措施。为确保所选择控制措施的充分性，必要时可以进行再评估，通过控制措施实施的有效性，评价残余风险是否可以接受。

记录风险结果

1．文件发布前得到批准，以确保文件是充分的；

2．必要时对文件进行评审、更新并再次批准；

3．确保文件的更改和现行修订状态得到识别；

4．确保在使用时，可获得有关版本的适用文件；

5．确保文件保持清晰、易于识别；

6． 确保外来文件得到识别；

7．确保文件的分发得到适当的控制；

8．防止作废文件的非预期使用，若因任何目的需保留作废文件时，应对这些文件进行适当的标识。

1．风险评估的角色

信息安全风险评估（以下简称风险评估）在具体实施过程中将涉及多个参与方，参与方在评估中扮演不同的角色。在一个完整的信息安全风险评估当中，一般包括主管机关、信息系统拥有者、信息系统承建者、信息安全评估机构以及信息系统的相关机构。

2．风险评估的职责

其各自的职责为：

（1）行政审批

主管机关具有风险评估的行政审批权力，主要负责提出、制定并批准本部门的信息安全风险管理策略，领导和组织本部门内的信息安全评估工作。基于本部门内信息系统的特征以及风险评估的结果，判断信息系统残余风险是否可接受，并确定是否批准信息系统投入运行。检查信息系统运行中产生的安全状态报告；定期或不定期地开展新的信息安全风险评估工作。

（2）组织协调

信息系统拥有者具有风险评估的组织协调权力，将负责制定安全计划，报主管机关审批；组织实施信息系统自评估工作；配合强制性检查评估或委托评估工作，并提供必要的文档等资源；向主管机关提出新一轮风险评估的建议；改善信息安全防护措施，控制信息安全风险。

（3）措施整改

信息系统承建者应根据对信息系统建设方案的风险评估结果修正安全方案，使安全方案成本合理、积极有效，在方案中有效地控制风险；规范建设，减少在建设阶段引入的新风险；确保安全组件产品得到了相关机构的认证。

（4）具体实施

信息安全评估机构提供独立的信息安全风险评估；对信息系统中的安全防护措施进行评估，以判断这些安全防护措施在特定运行环境中的有效性以及实现了这些措施后系统中存在的残余风险；提出调整建议，以减少或根除信息系统中的脆弱性，有效对抗安全威胁，控制风险；保护风险评估中获得的敏感信息，防止被无关人员和单位获得。

（5）辅助支持

信息系统的相关机构为风险评估提供辅助支持，遵守安全策略、法规、合同等涉及信息系统交互行为的安全要求，减少信息安全风险；协助风险评估机构确定评估边界；在风险评估中提供必要的资源和资料。

风险评估形式

根据评估的目的、评估方与被评估方的关系，以及评估方和被评估信息资产的关系、评估的深浅程度等不同的划分原则，国内外现存的风险评估也有多种形式，本指南所指风险评估形式主要以评估的发起方为划分依据。大体可分为自评估和他评估两大类，自评估是由被评估信息系统的拥有者发起的，并依*自身的力量，对其自身的信息系统进行的风险评估活动。他评估则相反，通常是被评估信息系统的拥有者的上级主管机关或业务主管机关发起的，依据已经颁布的法规或标准进行的，具有强制意味的检查活动，是通过行政手段加强信息安全的重要措施。他评估也是经常提及的检查评估。无论自评估还是他评估，都可以通过委托第三方专业评估机构进行评估的方式来进行，这就是委托评估。

项目研究风险评估报告【第四篇】

主要特点

水利信息化工程与传统的有形水利工程不同，它至少具备四个显著的特点：一是复合，项目建设是水利专业技术和信息技术的复合;二是集成，是各种高新技术包括远程自动化监控技术、通讯网络技术、数据库技术、3技术、数学模型技术、系统集成技术等的相互融合集成;三是共享，项目建设必须实现网络资源和信息资源的最大程度共享;四是创新，主要是指水利信息化的建设模式尚在探讨阶段，需要建设者在实践中进行技术创新。

涵盖范围

水利信息化项目的涵盖范围，虽然目前还没有明确的定义，但按技术特性归类，应包括一系列与水利政务、业务管理及工程设计、建设和管理等方面有关信息的采集、信息网络系统建设以及业务应用系统软件的开发集成。水利信息化项目的涵盖范围，虽然目前还没有明确的定义，但按技术特性归类，应包括一系列与水利政务、业务管理及工程设计、建设和管理等方面有关信息的采集、信息网络系统建设以及业务应用系统软件的开发集成。

原则

可研报告的编制应贯彻执行我国信息化建设的“统筹规划、国家主导、统一标准、联合建设、互连互通、资源共享”的指导原则，在对工程项目的建设条件和需求进行充分调查分析的基础上，对系统的规模、结构和功能、设备主要技术指标以及配套工程等进行方案比较，提出初选意见和可行性评价。

规程规范

可研报告的编制应参照《水利水电工程可行性研究报告编制规程》(以下简称《水电工程可研报告编制规程》)、《广东省水利信息系统工程建设设计指导书(试行)》(以下简称《指导书》)及相关的技术规程规范进行。

重点环节

计算机网络ip地址是计算机的重要标志，是网络能否互联、信息资源能否共享的首要问题。由于国家和水利行业的信息化标准体系目前尚未正式刊布，现行的计算机网络ip地址分配通常都是由地区或行业根据实际需要临时作出的，技术标准的级别较低，执行起来有一定困难。

《指导书》中的ip地址分配及其域名设计、是依据水利部下发的原则性设计指导书，在已完成的《广东省三防指挥系统工程项目可行性研究报告》基础上统一设计的，既考虑了目前广东省水利信息网的连网需要，也为下一步全省信息化标准体系正式刊布后的修改或转换留下余地。因此，严格按照《指导书》的规定做好自己区域或部门的计算机ip地址和域名分配的规划管理和分配，是执行有关技术规范规程的重点环节之一。

政府系统专网平台建设走在前面的个别地区，可按当地政府统一分配的ip地址方案设计，将设计方案报省水利厅备案，便于做好相互之间的转换处理安排。

(1)综合说明。包含工程背景、工程建设的必要性，工程建设任务和实现目标等方面的论述;把握论证理由充分、实现目标明确的原则。

(2)系统的总体结构与功能。包括系统的组成与功能、系统内部界面划分、系统的体系结构和层次结构等，并绘出系统的拓扑图或物理结构模型图(见附图参考式样)。

(3)设备主要技术指标、数量以及配套工程量。包括各分支子系统或模块的面向任务、结构、功能、设备类别、数量和技术指标，以及相应的附属设施和配套工程种类分项(形式、工程量等)汇总表。

(4)系统的可靠性、实用性和安全性。主要是对系统的总体方案、设备选型和技术性能指标能否符合有关规范规程及工程的实际需要进行论述，重点是系统的安全性。

(5)工程实施计划。列出工程建设计划时间，各分支系统或部分的进度及相应的资金安排计划。此外，还应根据广东省发展计划委员会和经济贸易委员会《关于核准固定投资项目招标投标方式和范围有关事项的通知》(粤计资[2001]652号)的要求，提出项目的发包初步方案。

(6)工程管理设计。主要拟定项目建设和运行的管理机构，并根据(参照)有关标准作出运行费用估算及资金来源说明等。

(7)论证工程建设对环境影响的评价。仅在工程包含大功率的电磁波辐射，或配套工程涉及对周边环境、景观有可能产生破坏或者影响的开挖和建筑项目的前提下才需要进行论证。

(8)工程建设投资估(概)算。由于现有的设计定额很少包括信息系统工程的设备和软件费的标准，应由相应专业的技术人员进行市场调查、将设备和软件的购臵价提交概预算编制人员，按规定的估(概)算编制规程作出工程建设投资估(概)算。

(9)经济评价。包括工程效益、工程经济合理性和财务可行性分析。应依据《建设项目经济评价方法与参数》(国家计委和建设部1993年颁发)以及《水利建设项目经济评价规范(sl72-94、水利部水利水电规划总院1994年颁发)进行编制。

与外部系统的衔接安排及之间的边界划分

由于水利信息系统与外部系统的关联密切、共享要求高的特点，任何一个信息系统工程，只要不是在孤立的环境条件下建设的，都应该在可研报告中对新与旧(若有的话)、点与面以及内与外三者之间的衔接及边界作出合理的安排和划分。否则，就没有回答工程是否存在重复建设以及能否最大程度地实现网络资源和信息资源共享的问题。

多媒体演示汇报稿制作

完成可研报告的编写后，便进入专家评审和计划部门审批程序。可研报告编制单位不可避免地要在评审会上，以计算机多媒体演示的形式，向与会专家以及来自上级主管部门和计划部门等单位的领导作汇报。通过高水平制作的多媒体演示汇报，能够使与会的专家、领导和代表对整个工程项目的架构和要点留下深刻的印象，有利于他们对可研报告作出全面、客观的评价。因此，如何将大篇幅的可研报告浓缩为提纲式的讲稿，充分利用计算机powerpoint的功能，制作出简明、清晰、图文和音像并茂的多媒体演示汇报稿，也是可研报告编制单位的重要任务之一。

水利信息化是一项复杂的、涉及多学科的系统工程，其建设项目可研报告应由具有一定工作经验的相关技术人员编制。在编制单位不具备或不完全具备相关专业技术人员的条件下，为保证可研报告的质量，应委托具备条件的单位负责或通过与其它单位合作的形式进行。