经济可行性分析的目的

任务描述
相关知识
- 经济可行性分析
- 估算软件项目成本
- 第二代构造性成本模型建模方法
案例描述
闯关要求

任务描述

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

相关知识

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

经济可行性分析

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

估算软件项目成本

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

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

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

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

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

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

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

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

软件项目中的工作量估算的算法模型可以基于一个简单的公式：Effort=A×SizeB×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×SizeB×M，Boehm基于他自己的大型数据集提出对这一阶段的估算，系数A应该为2.94，指数B反映随着项目规模的扩大所需工作量的增长，它可以在1.1~1.24之间变动，与项目的创新程度、开发的灵活性、采用的风险处理过程、开发团队凝聚力，以及组织的过程成熟度水平等密切相关，由此得到下列计算公式：

PM=2.94×Size(1.1～1.24)×MM=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

1、

经济可行性研究的范围包括

A、

技术有效性

B、

管理制度

C、

效益分析

D、

开发风险
2、

（多选题）在计算协同电子商务平台开发项目总成本时要使用以下哪些主要因素？

A、

工作量成本

B、

硬件维护成本

C、

原料成本

D、

差旅费和培训费用
3、

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

若使用COCOMO Ⅱ的早期估计方法，假设系数A为2.94，指数b为1.1，其中M量化值为67（100满），则协同电子商务平台企业管理系统的工作量约为（使用科学计数法表示，四舍五入至小数点后两位）：

A、

3.36×107

B、

5.36×107

C、

7.36×107

D、

9.36×107