软件工程理论与实践第8期-3 可行性研究

最新推荐文章于 2025-05-15 11:55:45 发布

墨沫℡

最新推荐文章于 2025-05-15 11:55:45 发布

阅读量899

点赞数 30

文章标签：软件工程

本文链接：https://blog.csdn.net/qq_62174885/article/details/146704869

版权

第2关：经济可行性分析的基本概念以及软件成本预估

3 可行性研究

3-1 项目立项和可行性分析基本概念

第1关：项目立项

任务描述
本关任务：通过了解并学习项目立项的相关步骤以及相关概念完成右侧选择题。

相关知识
为了完成本关任务，你需要掌握：项目立项的相关步骤以及相应的定义。

软件项目立项步骤
任何一个完整的软件工程项目都是从项目立项开始的，项目立项的过程大致包括四部分：项目发起、项目论证、项目审核、项目立项，以协同电子商务平台项目为例：

1.项目发起阶段：若要发起协同电子商务平台项目的研发工作，需要寻求他人的合作和单位的支持，此时应将平台研发工作的目的和必要性阐述清楚，并通过书面形式提交，这种文档被称为项目建议书或项目发起文件。

2.项目论证阶段：项目论证过程就是可行性研究过程。在项目研发工作之前，根据项目文件和实际情况，对项目进行深入细致的技术经济论证，目的是研究在当前时间和资源的约束下，研发这种软件项目的必要性。

3.项目审核阶段：项目论证通过后，需要通过企业高层部门层层审核，最终决定项目是否进行研发。

4.项目立项阶段：为了提高当前协同电子商务平台系统的质量，需要加强项目各个阶段的管理，在审核通过之后，需要定制相关项目计划书，形成正式的立项书面声明。

闯关要求
根据提示，在右侧面板选择你认为正确的选项，平台会根据标准答案进行打分。

第2关：可行性研究的基本概念和内容

任务描述
本关任务：通过了解并学习可行性研究的定义以及相关内容完成右侧选择题。

相关知识
为了完成本关任务，你需要掌握：1.可行性研究的定义，2.可行性研究的内容。

可行性研究的定义
软件项目的可行性研究(Feasibility Analysis, SA)是项目前期工作中最重要的内容，它是在项目投资决策前对软件工程研发进行全面的技术经济分析论证的科学方法和工作阶段。

所谓建设项目的可行性研究，即所谓“可以行得通的方案研究”，通常指的是在投资决策前，对与准备研发项目有关的技术、经济和社会因素等各方面情况进行深入细致的调研；对各种可能的研发方案进行认真的论证，同时要对研发之后项目的经济效益进行科学的预测和评价。

可行性研究的内容
软件项目的可行性研究需要从多个角度去分析，经过细致的论证从而对最后的决策提出结论性的意见，根据GB/T 8567-2006标准，大致分为四大部分，即：技术可行性分析(Technical Feasibility Analysis, TFA)、经济可行性(Economic Feasibility Analysis, EFA)、社会因素可行性分析(Social Factors Feasibility Analysis, SFFA)和风险分析(Risk Analysis, RA)，仍然以协同电子商务平台项目为例：

1.技术可行性分析：要开发协同电子商务平台项目，应对公司先有技术条件能否满足当前平台项目研发条件进行考察，若不满足，则立即考虑补救措施，如更新当前公司的技术框架，增加或减少相应的硬件设备等等。

2.经济可行性分析：又称为“成本-效益分析”，经济可行性分析是比较复杂且相对比较重要的阶段，通过对基础投资、研发成本以及预期的效益进行分析，最终得出在公司投资这种项目的必要性。

3.社会因素可行性分析：主要包含两部分，即：法律可行性分析和用户使用可行性分析。法律可行性分析是指当前平台项目研发工作以及内容是否符合我国相关法律法规的要求，在软件著作权方面是否侵犯他人权益，以及确定相关责任人等。用户使用可行性分析是指，当前平台项目的研发是否能满足用户素质的要求，即用户能否用的明白，用的顺畅。。

4.风险分析：主要考虑平台项目在实施过程中可能需要的各种风险因素，以及每种因素可能出现的概率和出险后造成的影响程度。

3-2 对现有的系统进行分析

第1关：对现行系统分析的基本概念

任务描述
本关任务：明确对现行系统进行分析的意义和步骤以及相关的基本概念。

相关知识
为了完成本关任务，你需要掌握：1.如何分析现行系统，2.系统流程图的相关概念。

对现行系统进行初步分析
对现行系统进行初步分析是可行性研究当中重要的一步，新系统的一些信息主要来源于现行系统同时要根据实际需求完成现行系统的部分功能，并在此基础上对现行系统中存在的问题进行改善和修复，分析现行系统的主要方法就是分析系统的各个部分功能模块，绘制出系统流程图。

系统流程图
系统流程图(System Flow Chart, SFC)是一种概括描绘项目物理模型的图示，主要以黑盒子的形式用图形符号描绘系统中的每个组成部分来表达数据在系统各部分中的流动情况，在绘制的时候一般遵循“自顶向下、逐层分析”的原则，根据GB/T 1526-1989，系统流程图一般包括以下内容：

1.指明数据存在的数据符号，这些数据符号也可指明该数据所使用的媒体。

2.定义要执行的逻辑路径以及指明对数据执行的操作的处理符号。

3.指明各处理和（或）数据媒体间数据流的流线符号。

4.便于读、写系统流程图的特殊符号。

绘制系统流程图的工具有很多，我们以starUML为例，在绘制系统流程图中，根据GB/T 1526-1989，一般使用以下几个符号：

第2关：请画出数据库信息处理流程

案例描述
在协同电子商务平台项目的研发过程中，需要将客户表单信息从客户数据库中取出，交给客户登录处理模块进行处理，请使用starUML进行绘制。

闯关要求
根据提示，使用starUML工具，在右侧的虚拟机上绘制出该案例所描述的系统流程图，并将结果保存在桌面上workspace/myshixun/系统流程图/submit_step_2/下，并将文件保存为step.mdj。注意，系统流程图符号内的文字描述使用案例中给出的加黑字体的描述方式。

第3关：请画出文件信息处理流程

案例描述
在协同电子商务平台项目的研发过程中，需要从订单管理模块中生成客户订单文件，并将其传送至订单文件系统中进行存储，请使用starUML进行绘制。

第4关：系统流程图的绘制

案例描述
根据提示，在右侧的虚拟机内作答，将电子商务系统中的网上商店模块绘制成相应的系统流程图，模块的功能描述具体如下：

为了完成商品展示的功能流程，需要从商品信息数据库中取出商品信息表单；商品订购功能流程也需要商品信息表单，同时为了生成订购单也需要从客户信息数据库中取出相应的客户信息表单；完成商品订购之后，会通过销售订单管理模块完成销售订单的生成功能，最终将销售订单存入磁盘的订单信息存储系统中。

3-3 技术可行性分析和经济可行性分析

第1关：技术可行性分析

任务描述
本关任务：根据相应的协同电子商务平台案例学习技术可行性分析的必要性以及撰写技术可行性报告部分的基本内容。

相关知识
为了完成本关任务，你需要掌握：1.技术可行性分析的必要性，2.技术可行性分析的基本内容。

技术可行性分析的必要性
项目的建设规模与产品方案确定后，应进行技术方案、设备方案和工程方案的具体研究论证工作。技术、设备与工程方案构成项目的主体，体现软件项目的技术和生产力水平，同时技术性可行分析也是项目是否经济合理的重要条件，所以必须选择技术先进、合理的最佳建设方案

技术可行性分析的基本内容
根据软件设计文档国家标准（GB8567-2006）的要求，技术可行性章节应该主要包含以下内容：
1.在当前的限制条件下，该系统的功能目标能否达到。
2.利用现有的技术，该系统的功能能否实现。
3.对开发人员的数量和质量的要求，并说明这些要求能否满足。
4.在规定的期限内，本系统的开发能否完成。
除了上述内容之外，技术可行性部分应该对当前开发所使用的主流研发框架和架构做简要的介绍和说明，不限于图表和文字等方式。

第2关：经济可行性分析的基本概念以及软件成本预估

任务描述
本关任务：掌握经济可行性分析的目的，根据相应的协同电子商务平台案例学习成本预估的目的以及相应的预估方法

相关知识
为了完成本关任务，你需要掌握：1.经济可行性分析的目的，2.软件成本估计的基本概念，3.如何预估软件成本。

经济可行性分析
经济可行性分析主要是把系统开发和运行所需要的成本与得到的效益进行比较，进行成本效益分析，也就是根据经济学的方法分析当前系统是否值得研发。

估算软件项目成本
在可行性分析阶段，必须计算出开发当前软件项目的价格，计算价格首先需要估计完成项目所需要的成本，这包括计算完成各个活动的所需要的工作量，然后计算所有活动的工作量，我们必须客观地计算软件成本，才能准确地预测开发软件的成本，一旦对可能的工作量有合理的估计，接下来才能计算出价格，这不只是简单的成本+利润，还有很多因素影响软件项目的价格，在计算软件开发项目总成本时要使用以下3个主要因素：

1.工作量成本（支付给软件工程师和管理人员的费用）
2.硬件维护和软件支持的成本。
3.差旅费和培训费用。

对于绝大多数项目，主要的成本是工作量成本，显然，所掌握的用于估算成本的信息是有限的，所以必须首先做出贴近的估算，然后再加上一个很大的应急开支。

在项目早期阶段对系统开发成本进行精确估算是相当困难的，常用的近似估计技术主要有以下两种：

1.基于经验的技术：使用之前项目和应用领域的经验估算要求的未来工作量，即分析者主观给出所需要的工作量的一个估计。

2.算法成本模型：使用一种公式化的方法计算项目的工作量，基于对产品属性（规模、过程特点和参与员工的经验）的估计。

基于经验的估计技术依赖分析者之前的项目经验以及这些项目中有关软件开发活动上的实际工作量投入，困难在于一项新软件项目可能和之前的项目没有太多共同点。软件开发变化非常快，软件开发项目经常使用一些不熟悉的技术，例如在开发协同电子商务平台的过程中，前端技术栈更新为最新的vue3.0框架等等，如果分析者没有使用过这些技术，之前的经验可能对估算需要的工作量没有帮助，从而使估算工作更加困难。

前面介绍了基于经验的估算方法，接下来介绍如何使用数学公式预测项目的成本。

软件项目中的工作量估算的算法模型可以基于一个简单的公式：Effort=A×Size
B
×M其中：

A：一个常量因子，依赖于组织的实践经验和所开发的软件类型。
Size：一个对软件的代码规模或是用功能点或应用点表示的功能的估算。
B：表示软件复杂度，其值通常在1～1.5之间。
M：一个乘数因子，反应了过程、产品、开发属性，例如软件的可依赖性需求，以及开发团队的经验等综合因素。交付的系统中的源代码行数（Source Lines of Code，SLOC）是基本的规模度量标准，但遗憾的是，在项目早期阶段，估计size通常是个难题，而且B和M的估算也带有主观色彩，为了解决这些问题，后期提出了许多成本估算的新一代模型。

第二代构造性成本模型建模方法
目前最著名的算法性成本建模方法和工具是第二代构造性成本模型(Constructive Cost Modeling Ⅱ, COCOMO Ⅱ)模型，获得该模型的途径是这样的：首先从大量的大小不同的软件项目中收集数据，然后通过对这些数据的分析找出于观察资料最相符合的公式，这些公式将系统的规模、产品、项目和团队因素等于开发系统的工作量联系起来，并且COCOMO Ⅱ考虑了现代的软件开发方法，例如使用动态语言的快速开发、基于复用的开发、数据库编程等等。作为COCOMO Ⅱ模型的一部分子模型包括以下内容：

1.应用组合模型
它对所需的工作量进行建模，所开发的项目是由可复用构件、脚本或数据库编程创建而得，软件规模估计基于应用点，这需要考虑预期复用部分所占得比例来调整基于应用点总数的估算，因此，对于原型系统开发项目的工作量计算的最后公式是：PM=(NAP×(1−%reuse/100))/PROD，其中：

PM：以人月为单位的工作量。
NAP：交付系统的应用程序点的总数。
%reuse：在开发中重用的代码量的估计。
PROD：应用点生产率。

项目中NAP的值往往由以下几个指标导出：
(1).显示的单独的屏幕和网页的数量
(2).显示的产生报表的数量
(3).命令式程序设计语言（如Java）中模块的数量
(4).脚本语言或数据库编程的代码行数

PROD的值由COCOMO的开发者给出了一个标准的表格，在项目可行性研究的过程中，可以直接套用：

开发者的经验和能力   非常低   低   一般   高   非常高
软件工具的成熟度和能力   非常低   低   一般   高   非常高
PRO(NOP/月)   4   7   13   25   50
2.早期设计模型
项目可行性研究阶段尚未进行详细设计，只有用户的需求，所以此时我们仅仅对项目做一个大略的成本估计，因此可以提出一些假设来简化问题。上一小节中，我们提到了简单的估计模型，即Effort=A×Size
B
×M，Boehm基于他自己的大型数据集提出对这一阶段的估算，系数A应该为2.94，指数B反映随着项目规模的扩大所需工作量的增长，它可以在1.1~1.24之间变动，与项目的创新程度、开发的灵活性、采用的风险处理过程、开发团队凝聚力，以及组织的过程成熟度水平等密切相关，由此得到下列计算公式：

PM=2.94×Size
(1.1～1.24)
×M
M=PERS×PREX×RCPX×RUSE×PDIF×SCED×FSIL
其中：

PERS：个人能力。
PREX：个人经验。
RCPX：产品的可靠性与复杂性。
RUSE：所要求的复用。
PDIF：平台困难程度。
SCED：进度。
FSIL：支持设施。

项目中不同部分的指标一般由6个指标量化，从1～6，例如个人能力（PERS）为1表示当前参与研发的人员个人能力较差，下面给出一个实例：

评价指标   量化值
PERS   2
PREX   4
RCPX   6
RUSE   3
PDIF   1
SCED   2
FSIL   3
3.复用模型
复用模型用于估计集成可复用代码或已生成代码所需的工作量。复用技术是当前软件开发常用的技术，即将之前封装好的构件拿来重新使用，COCOCM Ⅱ将复用代码分为两类：白盒代码和黑盒代码，黑盒代码就是那些不用做改动的代码，我们可以认为黑盒代码的开发工作量为0，且它的规模不会影响到总体工作量。白盒代码需要将新代码或其他复用构件的代码改编整合到一起，它需要一些开发工作量，以下是3个影响复用白盒代码构件所需工作量的因素：

(1).评估某个构件是否可以在开发系统中复用所需的工作量。
(2).理解复用代码所需的工作量。
(3).修改复用代码并集成到开发系统中所需的工作量。

前面介绍的早期设计模型计算的开发工作量是基于系统的总代码行数的，但是我们需要估计的代码规模还包括开发不能复用的构件所写的新代码的工作量以及复用和集成已存在代码的额外工作量，这样的额外工作量叫做ESLOC，它相当于新的源代码的行数，公式为：
ESLOC=(ASLOC×(1−AT/100)×AAM)
其中：

ESLOC：新源代码的等价行数。
ASLOC：必须修改的复用构件的代码行数。
AT：可以自动修改的复用代码所占的比例。
AAM：改写调整因子，反映了构件复用时所需的额外工作量。

改写调整因子（Adaptation Adjustment Multiplier，AAM）调整估算以反映复用代码需要的额外的工作量，一般来说，AAM的计算公式如下：
AAM=AA+SU+AAF其中：

评估因子(Assessment Factor，AA)：评估因子表示决策构件是否能够进行复用的工作量。
理解部分(Understanding Component，SU)：表示理解要复用的代码以及工程师熟悉这些代码所需的工作量。SU的范围一般为50~10，50代表复杂的非结构化代码，10表示书写良好的面向对象代码。
改动部分(AAF)：表示修改这些复用代码的成本。

其实，我们估计ESLOC的根本目的，是要用它估计Size，这样我们直接令ESLOC=Size，然后将它带入到标准工作量公式，就可以得到我们估计的复用工作量。

4.后体系结构模型
当设计出系统体系结构之后，就可以对软件规模做更精确的估算，但是在可行性研究阶段，尚未进行详细的结构设计，所以这部分估算技术将在软件项目管理中详细介绍。

案例描述
现在进行协同电子商务平台项目企业管理系统部分的工作量估计，整个项目企业管理的不同功能点的代码量如下图所示（单位：SLOC）：

功能点名称   代码行量
销售订单管理   4122
采购订单管理   11397
库存管理   3332
应收付款管理   9461
总账管理   13177
系统维护   6242
决策分析   9372

第3关：经济/效益分析方法

任务描述
本关任务：根据相应的协同电子商务平台案例学习成本/效益分析的概念和基本方法。

相关知识
为了完成本关任务，你需要掌握：1.投资回收期法进行成本/效益分析，2.投资收益率法进行成本/效益分析。

成本/效益分析方法
软件工程经济可行性分析部分最重要的三个步骤分别为：成本估计、运行费用、新系统带来的效益，成本估计的具体方法在上一小节已经做了详细的介绍，成本/效益分析(Cost/Benefit Analysis)阶段应该比较新系统的开发成本和经济效益，以便从经济角度判断这个系统是否值得投资，下面介绍两种经济分析方法：投资回收期法(Payback Period Method, PPM)和投资收益率法(Return on Investment Method, RIM)。

投资回收期法
软件项目的投资回收期指的是当前项目的累计净收益能够覆盖最初投资的时间，单位一般为年，显然，投资回收期越短，项目收益的速度越快，根据定义得出投资回收期的计算公式为：

其中N d表示投资回收期，C表示年初没有收回的成本(Cost)，CF表示当前年度的现金收益(Cash Flow)，这是个简单的投资回收期公式，项目组可根据实际情况拓展对投资回收期的建模。

求出投资回收期之后，就可以对照行业内的平均投资回收期，如果大于基准时间，则需要慎重考虑投资的必要性了。

投资收益率法
投资收益率又被称为投资利润率，它是指在投资方案在达到设计一定生产能力之后一个正常年份的年净收益总额与方案投资总额的比率，类比于银行的年利率，投资收益率描述的就是投资当前项目的效益大小，如何计算这个投资收益率呢？我们设想把投资额存入银行，年底可以取出当前年份的收益，那么在系统时间寿命之内，我们取出的收益刚好等于投资额，那么计算公式就可以写成下面的形式：

其中，P为投资额，F i为第i年的收益，j就是投资收益率，求解出j之后和基准收益率i比较就可以得出当前项目是否值得投资。

案例描述
下面，通过一个真实的协同电子商务平台的案例来理解两种经济/效益分析方法的具体操作，同时根据案例完成右侧的选择题：

现在对协同电子商务平台项目做成本/效益分析，使用投资收益率法验证当前项目是否值得投资，项目的投资额 P 预估如下表所示（单位：万元）：

费用名称   金额（万元）
人员工资   101
采购设备、软件   50
办公费用   10
办公用品   3
调研费   6
资料费   2
鉴定费   2
培训费   5
上网费   17
协作费   6
市场开拓费   15
不可预见费用   3
合计   220
推算出项目的寿命为2年，设投资收益率为 j ，根据调查，该平台社会基准收益率 i 为2.33%，项目每年预计的收益 F i, 如下表所示（单位：万元）：

年份   收益（万元）
2021   100
2022   140

3-4 社会因素可行性分析以及风险分析

第1关：社会因素可行性分析

任务描述
本关任务：了解并掌握社会因素可行性分析的基本内容。

相关知识
为了完成本关任务，你需要掌握：1.法律可行性分析的具体内容，2.用户使用可行性分析的具体内容。

社会因素可行性分析
社会因素可行性分析主要考虑项目是否满足所有项目涉及者的利益、是否满足法律或合同的要求等，主要分为法律可行性分析(Legal Feasibility Analysis, LFA)和用户使用可行性分析(User Feasibility Analysis, UFA)。

法律可行性分析
法律方面的可行性问题很多也比较复杂，例如：合同责任、侵犯专利、侵犯版权等，软件开发人员对于这些问题可能不是很熟悉，所以要多调研相关的法律法规，多做研究，必要时请一些专业的团队进行面谈，避免在开发过程中因法律问题导致项目进度受阻。

用户使用可行性分析
除了从项目和开发者的角度进行可行性分析之外，调研人员还要从用户的角度进行分析，主要包括分析当前系统是否符合甲方单位的相关制度要求，是否符合用户的素质能力水平等。

第2关：风险分析

任务描述
本关任务：了解风险分析的基本概念和内容，通过一个真实的协同电子商务平台的案例掌握具体的风险分析方法。

相关知识
为了完成本关任务，你需要掌握：1.风险分析的基本概念，2.风险管理的基本步骤，3.风险分析的基本方法即头脑风暴法和Delphi法，4.风险应对的四种策略。

可行性研究风险分析
软件项目中的风险指的时一些不确定的因素或条件，会对项目产生正面或者负面的影响，能够预见可能影响正准备开发的软件的项目进度或产品质量的风险，是可行性研究阶段风险分析的重要任务，一般情况下风险管理的过程主要包括四个阶段，即：风险识别、风险分析、风险计划、风险监控。

1.风险识别：识别可能的项目风险、产品风险和业务风险。
2.风险分析：评估这些风险出现的可能性及后果。
3.风险计划：制定计划说明如何规避风险或最小化风险对项目的影响。
4.风险监控：定期对风险和缓解风险的计划进行评估，并随着有关风险信息的增多及时修正缓解风险的计划。

在可行性研究阶段我们只进行风险识别和风险分析，其他部分在软件项目管理阶段由相关人员细化。

风险识别
在可行性研究风险分析之前，要对当前项目的风险进行识别，这一阶段主要是发现可能对软件工程过程、正在开发的软件或者开发组织产生重大威胁的风险，风险识别可以通过调研、项目组对可能的风险集体讨论或凭借之前项目中出错的经验识别风险，同时可以生成如下所示的风险检查表：

风险分析
在风险分析过程中，必须考虑每个已识别的风险并针对该风险的可能性和严重程度做出判断。我们不可能对每个风险的可能性和严重程度做出精确的判断，但是可以对不同风险做出一个粗略的影响等级。

风险出现的可能性程度可以是：低、中、高、极高，而风险的严重程度可以是可以忽略的、可以容忍的、严重的、灾难的，接下来介绍两种比较常用的风险分析方法，头脑风暴法(Brain-Stroming, BS)和德尔菲法(Delphi)。

头脑风暴法
头脑风暴法最初由美国BBDO广告公司奥斯本提出，是一种激发创造性思维的方法，它通过小型会议的形式，让所有参会者处于放松自由的环境中，通过在有效的引导的条件下，同时互相交换思想来激励参与者的灵感和创意，头脑风暴法有两种形式，即：形式化（结构化）方法、非形式化（非结构化）方法。

形式化分析方法是由主持人提出问题，由参会者一个接一个提出自己的见解，没有新的建议或达到建议上限时可以跳过本轮问题，非形式化方法是指团队成员滚动式自由提出自己的看法，鼓励成员提出尽可能多的主意，以形式化方法和协同电子商务平台项目为例，具体的分析流程大致如下：

1.准备阶段：
确定本次会议的主题，即对要研发的协同电子商务平台的不同类型风险进行初步评估，确定不同类型的分型的可能性和严重程度，设定问题所要达到的目标，即形成一个初步的风险审查表，以及在会议的过程中，需要准备讨论的问题以及足够多的相关资料。同时确定会议的地点和时间，参会人数一般控制在5～20人之间，有1～2名主持人，以及1～2名记录者。

2.热身阶段：
由主持人宣布本次会议的主题和目的，同时活跃会议的气氛，让所有的参会者感到舒适、自由。

3.自由畅谈阶段：
主持人根据提前准备的问题，逐条展开，由参会者给出见解和意见，注意在讨论的过程中，不要约束参会者的思维和想法，鼓励其畅所欲言，对于提出的见解和看法在讨论过程中不做质的约束，多多益善，在讨论过程中，禁止对参会者的见解做出评判，谈论过程中由记录员进行记录。

4.会后整理阶段
将大家的见解和对不同风险类型给出的评分进行整理、筛选和平均，最后形成风险审查表并给出结论。

德尔菲法
德尔菲法，又称为专家调查法，也是比较著名的风险分析方法，起源于20世纪40年代，由兰德公司首创，它利用专家知识，通过群体的高效沟通和交流来解决复杂问题，我们仍然以当前协同电子商务平台为例，来说明Delphi法的具体流程：

1.首先要组建一支软件项目风险分析和协同电子商务平台领域的专家小组，5～20人即可，确定讨论的课题。

2.编制本次协同电子商务平台的风险分析调查表附上相关的资料，并交给各个专家进行打分同时给出自己的见解，调查表如下图所示：

风险类型   可能性   严重程度   打分理由   意见和建议
低估了项目开发所需要的时间（1）
人员所需的培训跟不上（2）
低估了软件的规模（3）
低估了需要修复的缺陷比例（4）
需求发生了变更，主体设计要返工（5）
软件工具无法以一种集成化的方式一起使用（6）
软件代码生成工具生成的代码效率低（7）
可复用构件中故障必须在构件复用前被修复（8）
可能性有三种：低（1分）、中（2分）、高（3分），严重程度有四种：可忽略的（1分）、可容忍的（2分）、严重的（3分）、灾难性的（4分）

3.对前一轮的问卷进行整理、分析和综合，得出结论，形成结论表，如下表所示：

其中，每个风险的左半面填写可能值，右半面填写严重程度，将这个对照表分发给参与者供他们参考。

4.重新进行新一轮的调查讨论，即回到步骤2，再进行分析和整理，直到各个专家达成共识。

德尔菲法和头脑风暴法的优缺点对比
德尔菲法   头脑风暴法
优点   充分发挥专家的作用，集思广益，准确性高有针对性，能充分发挥不同专家特长   思想不被束缚，激发了想象力，有助于从一个新的角度理解当前的风险，并且收敛速度较快
缺点   权威人士的意见可能会对其他参与者的意见产生影响，一些碍于情面或出于自尊心，提出一些不正当的建议影响最后的结果，从而导致很长时间的迭代都没有达成共识   可能由于技术理论上的不足，难以切中时弊，无法提出具有针对性的见解，而且过程比较松散，汇总起来比较困难
风险应对策略
总的来说有四种应对不同类型风险的策略，即：规避策略、转移策略、减轻策略、接受策略。

1.规避策略：直接或间接改编项目的计划来规避风险，保护当前项目不受到影响。以协同电子商务平台项目为例，针对于项目平台“低估项目整体开发时间”的风险，可以考虑与有关专家进行洽谈，确认能否通过使用更先进的web技术框架来提高开发效率，以及能否改变某些模块设计思路避免高风险的算法等。

2.转移策略：通过将风险转嫁给第三方的方式，降低项目的开发风险，这种策略并没有消灭风险，而是将风险以支付报酬的形式转移出去，以协同电子商务平台项目为例，在开发企业管理系统中，若希望实现人脸识别登录功能，企业内部训练一个模型会有不稳定的风险，所以项目负责人决定将该模块转交给外包公司进行开发，并支付一定的报酬，从而将项目风险转移了出去。

3.减轻策略：通过某些方法，最大可能减轻不利风险的影响程度，例如，在协同电子商务平台的企业管理系统的应首付款模块研发过程中，可以考虑通过简化付款和收款的流程，同时接到alipay的接口的方式降低支付流程中交易链条中断的重大风险。

4.接受策略：面对相应的风险，不改变项目计划或者没有应对的策略，此时要对项目制定风险监控方法，同时要做好应对风险发生的准备。