软件估算规程.doc

软件估算规程

文件编号：CMMI/09

CMMI文件——
软件估算规程
V4.0

起 草 部 门： 品管部
管 理 部 门： 品管部
撰 写 人：
审 核 人： EPG
批 准 人： EPG
发 布 日 期:
目 录
1 目的 4
2 适用范围 4
3 术语定义 4
4 估算时机和参与人员 6
5 估算原则 6
6 估算流程图 8
7 估算前准备工作 8
8 编码与单元测试工作量估算 9
8.1 Delphi估算过程 9
8.2 功能点估算过程 10
9 项目总工作量估算 17
9.1 估算过程描述 17
9.2 工作产品 18
10 代码规模估算 18
11 进度估算 19
12 缺陷估算 19
13 估算差异分析 19
14 度量 19
15 附录一：PERT法介绍 20
16 附录二：功能点计算场景示例 21

- 2 -
软件估算规程
1 目的
软件估算的目的是通过对软件项目开发规模和工作量的估算，确认项目开发的成本、开发周期，以作为项目投标、立项的依据，并指导项目进度计划、资源规划及项目成本控制。给软件开发中的活动、工作产品以及各种角色（包括用户）建立适当的预期。以达到支持产品需求、本组织的需求、顾客的需求以及达到他们对该项目提出的目标，确保交付质量合格的产品。
软件项目的估算不是一次估算过程，通常会对项目估算多次。 例如在项目立项时，通过估算，项目组与公司达成成本承诺；在项目需求分析阶段， 通过估算以确定项目的初步开发计划；在项目概要设计阶段，通过功能点明细估算确定项目的明细开发计划；在需求变更时，变更内容的估算与需求保持一致，尽可能满足项目的进度安排和预算。
对项目的估算通常包括对软件规模（代码行）、工作量（人天）、成本和关键计算机资源的估算。
本文档作为软件质量体系中的估算过程的具体规范，用来指导本公司项目过程中估算活动的实施。
2 适用范围
适用于公司内以下情况估算：
l 项目报价估算：在项目的投标活动中，根据《业务需求报告》或者系统原型，进行项目规模和工作量估算，为软件项目报价提供数据依据。
l 立项成本估算：软件项目立项时，根据《项目立项报告》和《业务需求报告》等，进行项目规模、成本和工作量估算，为公司决策是否立项提供数据依据。
l 软件开发估算：在软件需求分析、概要设计的基础上，根据需求分析说明书/界面原型、概要设计说明书，进一步精确估算规模、工作量、关键计算机资源，为项目进度安排提供数据依据。
l 项目重大偏离或需求显著变更时的估算：重新作局部估算或调整估算，使项目的策划符合变更的要求。应组织原参与人员再次估算，为重新调整项目计划或项目是否继续进行决策时提供数据依据。
3 术语定义
l 功能点分析方法（function points analysis，FPA法）：是一种基于软件需求特性对软件项目的规模进行估测的方法。1979年IBM公司的Alan Albrech首先开发了计算功能点的方法，这种方法是通过评估和计量软件产品所需的内部基本功能和外部基本功能数目，再根据技术复杂度因子（权重）对这些软件功能计数进行量化，得到软件研发项目规模的最终结果。根据本公司开发现状和产品的特点，运用了功能点分析方法的思路，并对该方法做了相应的简化和修改，形成了具有本公司特点的功能点分析方法。
l Delphi法：德尔菲法(Delphi)又称专家判断法，专家估算法或专家打分法，依据系统的程序，采用匿名发表意见的方式，通过多轮次调查专家的看法，经过反复征询，归纳，修改，最后汇总成专家基本一致的看法，作为预测的结果。Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别。它是一种鼓励参加估算的人员之间就相关问题进行讨论的方法。
l DET（Data Element Type）：是一个以用户角度识别的，非重复的有业务逻辑意义的字段。通过一个基本处理过程的执行，对内部接口进行维护或从内部接口/外部接口中返回一个特定的、用户可识别的、非重复的字段，那么每个这样的字段算一个DET。
例如：添加一个外贸订单时需要保存“订单号码、订单日期、地址、邮编”，那么对于内部接口订单来说它的DET就是4个。
l FTR（File Type Referenced）：FTR是被事务操作读取或维护的ILF，或者是被事务操作读取的EIF。
l 平均值=AVERAGE (value1,value2,...)，多人对某项估算后的平均值。
l 标准偏差：每个样本数值与平均值的差的绝对值之和，除以样本个数。标准差越小说明所有数值越接近平均值。
l 规模估算的代码行：为本次项目新增代码行，包括新增和修改的代码，不包括完全重用代码，空行，注释行。
4 估算时机和参与人员

估算时机
估算内容
估算依据
建议估算
方法
估算负责人
估算参与人员
备注
项目报价估算
工作量估算
业务需求报告、方案等
Delphi法
客户经理
需求经理、架构设计师、研发经理/部门经理

立项成本估算
工作量估算
业务需求报告、立项报告、组织级类型分布基线等
Delphi法
产品经理（或授权需求经理）
需求经理、架构设计师、项目经理、研发经理/部门经理

软件开发初步估算
需求分析工作量、进度估算
业务需求报告
Delphi法
项目经理
需求经理、架构师代表、研发经理/部门经理、项目组
项目组由项目经理、架构设计师、测试负责人、中高级编码工程师等共同估算，估算结果作为项目组的估算值。
规模估算、工作量估算、进度估算
需求分析和界面原型、组织级类型分布基线、代码生产率基线等
Delphi法
项目经理
需求经理、架构师代表、研发经理/部门经理、项目组
软件开发明细估算
规模估算、工作量估算、进度估算
概要设计、组织工作类型分布基线、代码生产率基线
功能点法、Delphi法
项目经理
架构师代表、研发经理/部门经理、项目组

项目过程中发生重大偏离或需求较显著变更（需求变更的影响工作量在22人天以上）时的估算
工作量估算、进度估算
变更需求或重大偏离情况说明
功能点法、Delphi法
项目经理
需求经理、架构师代表、研发经理/部门经理、项目组

5 估算原则
本公司的估算是通过估算项目组编码与单元测试的工作量，依据组织过程能力基线和典型项目性能基线，确定项目编码和单元测试工作量类型占项目总工作量的比例，按照既定的计算公式估算项目的总工作量。
l 采用组织过程能力基线和类似项目的过程性能基线相关内容作为估算依据。在此基础上根据项目特征进行合理的调整，若调整结果超出基线范围，应对调整原因做出分析和说明。
l 采用分解技术。本公司（又不仅限于本公司）开发工程师习惯了先做需求分解（且不论其细致程度），然后根据分解的各需求项，逐项估算出它的需求分析、设计、编码和测试的工作量，这已经成为了普遍的经验与理念。
本文中估算方法的思路是将需求分解到2-3级功能模块，采用历史数据作为计算的依据，同时采用Delphi、功能点方法估算，估算结果基于估算人员磋商取得一致的结果。
6 估算流程图

7 估算前准备工作
1） 成立估算小组，由估算负责人依据《项目开发责任书》组建估算小组。
2） 选择编码与单元测试工作量估算的方法，由估算小组确定。
3） 分解业务或功能模块，填写到《软件估算表》模版。估算负责人根据选定的估算方法，依据业务需求、需求分析或概要设计等文档，将模块分解到2-3级功能，分解尽可能细，并列入《软件估算表》中的“DELPHI估算表”、 “功能点估算表”。
注意事项：
l 估算的分解粒度以不超过3人天为准，超过时需要再细分，否则需说明原因；
l 对于选择“DELPHI”估算方法的，在制定估算表时应将关键模块单元测试任务单独列出来，以便估算单元测试工作量；
l 估算负责人整理好《软件估算表》后，应发给专家确认及审核，确保模块分解合理、正确。
l 《软件估算表》确认后，由估算负责人将相关的估算参考文档和《软件估算表》发放给估算专家。
4） 召开估算前的沟通会议。在正式估算前,估算负责人应组织所有估算专家召开估算前的沟通会议，讲解本次估算的注意事项，如：
l 估算负责人向专家介绍本次估算的内容、分解的需求项、项目的各种假设和限制条件；
l 介绍项目的特点：技术难度，代码可重用度，组件领用等情况；
l 统一估算的度量单位等；
l 明确非关键模块单元测试工作量比例系数；
以上沟通会议的目的是所有参与本次估算的人员对估算的内容达成一致意见，以此来确保估算的准确性。
8 编码与单元测试工作量估算
编码与单元测试工作量估算有两种方式：Delphi估算、功能点估算，各项目可以依据项目的特点，由项目估算小组确定选用的估算方法，可以选择其中一种估算方法，也可以多种估算方法并用。
下面针对每一种估算方法，对估算过程进行详细的描述。
8.1 Delphi估算过程
1） 专家独立进行估算（无讨论/咨询），估算过程不应受外界压力（如作者对估算结果的限定）的影响，专家的个人估算表格详见《DELPHI估算表》。
2） 估算负责人搜集各专家的估算结果，并做汇总表。详见《DELPHI估算表》。
l 平均值=AVERAGE (value1,value2,...)，多人对某项估算后的平均值。
l 标准偏差：每个样本数值与平均值的差的绝对值之和，除以样本个数。标准差越小说明所有数值越接近平均值。
3） 当估算偏差大于40%时，估算负责人应组织专家讨论偏差较大的需求项和假定，经过讨论后，各人对估算结果进行调整，并提交给估算负责人。如此不断反复，直至满足以下任何一项条件：
l 完成2轮估算；
l 估算结果收敛于一个可以接受的范围（偏差小于40%）；
l 所有专家拒绝对各自的估算结果进行修改。
4） 估算负责人负责汇集估算结果，确定对每项分解的需求项所需的编码、单元测试工作量（小时）。
l 关键模块单元测试工作量：因在估算表中已拆分为单独的估算项，不需要另做处理；
l 非关键模块单元测试工作量：在“相应模块的编码工作量”基础上乘以“非关键模块单元测试工作量比例系数”（由估算专家组确定），作为该模块单元测试工作量。
5） 估算负责人计算项目总的编码与单元测试的工作量。
6） 估算小组对最后汇总的估算结果进行审核，并对结果达成一致。
8.1.1 工作产品
DELPHI估算表
8.2 功能点估算过程
8.2.1 功能点估算方法使用场景
以下场景不适合采用功能点方法进行估算，如：
l SOA服务、组件【在项目中可以多次被使用到，如：Google Suggestion、JS Tree、Print、】、后台功能、数据库【Trigger、Stored Procedure】、服务类、平台二次开发、基于模板开发、数据口径确认；
l 非界面性的项目，建议不使用功能点估算。
8.2.2 功能点类型及权重介绍
功能点类型划分及权重设置如下表：
功能点划分类型
输入
输出
查询
内部接口
外部接口
权重
4
5
4
10
7
功能点类型说明：
1） 输入（EI： External Inputs）：这是一个基本的过程，在这个过程中，数据穿越外部边界进入到系统内部。这里的数据可能来自于输入界面，也可以来自于另外的应用。来自于系统外部的数据经过这个过程，将会被用来维护一个或多个内部接口数据或调用一个或多个内部接口。比如说一个新增用户的功能，即为一个外部输入。因为用户的信息从界面中输入，最终保存于数据表中。一般情况下，常见的新增、修改、删除都归为外部输入。
2） 输出（EO：External Outputs）：在这个过程中，派生数据由内部穿越边界传送到外部。一个EO也可以更新一个或多个内部接口数据。数据生成报表或者传送给其他应用的数据档案，这些报表或者档案从一个或者多个内部逻辑档案以及外部接口档案生成。
3） 查询（EQ：External Inquiries）：一个基本过程，这个过程中的输入和输出部分都导致数据从一个或者多个内部接口或外部接口中提取出来。输入过程不能更新任何内部接口数据，并且输出端不能包括任何派生数据。
4） 内部接口（ILF：Internal Logical File）：用户可以识别的一组逻辑相关的数据和接口，而且完全存在于应用的边界之内，并且通过当前应用维护。 这个主要分为：数据表、相关的XML、INI等数据文件、其他模块之间的接口（类接口、EJB接口、存储过程等等）。
5） 外部接口（EIF: External Interface File）：用户可以识别的一组逻辑相关数据和接口，这组数据和接口只能被引用。数据和接口完全存在于应用的外部，并且由另一个应用维护。这个主要分为：数据表、相关的XML、INI等数据文件、其他系统提供的接口（EJB接口、存储过程等等）。
ILF和EIF属于数据类型的功能点，EI、EO、EQ属于人机交互类型的功能点。
8.2.3 功能点计算规则
ILF和EIF的计数相对简单，在理解定义的基础上应能较好识别，这里主要描述EI、EO、EQ的计算规则。EI、EO、EQ的识别都是基于基本处理过程（Elementary Process）的。该过程对用户来说是一个有意义的最小的活动单位，并且是一个自包含的活动。
EI的计算规则：
① 从应用边界之外收到数据。
② 如果进入系统边界内的数据不是一个改变系统行为的控制信息，那么至少一个ILF应该被改变。
③ 对于已识别的处理过程，至少满足下面三个条件之一。
ü 该基本处理过程的逻辑与本应用系统中其它基本处理过程的逻辑不同。该基本处理过程应该具有唯一性。例如：不能存在两个完全一模一样的存盘操作。
ü 在应用程序边界内，该基本处理过程所使用的这组数据应该与其他基本处理过程所使用的数据不同。
ü 在应用程序边界内，基本处理过程所引用的ILF或EIF是不同于其它基本处理过程所引用的ILF或EIF。

EO和EQ通用计算规则：
必须全部满足以下内容才能被视为一个EO或EQ：
① 该操作向应用边界之外发送数据。
② 为了识别这个过程，以下三点必须满足一个：
ü 该基本处理过程逻辑上必须是唯一的，该唯一性是指其在应用程序中与其他EO或EQ的逻辑性上保持唯一。
ü 该基本处理过程所使用的数据应该是唯一的，该唯一性是指其在应用程序中与其他EO或EQ所使用的数据不同。
ü 该基本处理过程所引用的ILF或EIF文件应该是唯一的，该唯一性是指其在应用程序中与其他EO或EQ所引用的ILF或EIF文件不同。

EO的补充计算规则：
除了要满足上面的通用规则外，还要满足下面其中一条：
ü 在基本操作过程中至少包含一个数学公式或计算方法
ü 在基本操作过程中要产生派生数据
ü 在基本操作过程中至少要维护一个ILF
ü 在基本操作过程中要改变系统的行为

EQ的补充计算规则：
除了要满足上面的通用规则外，还要满足下面其中一条：
ü 基本操作过程从ILF或EIF中获取数据
ü 基本操作过程不能包含数学公式或计算方法
ü 基本操作过程不能生成派生数据
ü 基本操作过程不能维护任何一个ILF
ü 基本操作过程不能改变系统的行为
8.2.4 功能点复杂度计算
EO、EI、EQ复杂性取决于FTR和DET的数量。
EI中识别FTR规则：
ü 每一个ILF应该算做一个FTR。
ü 通过EI读取操作的每个ILF或EIF都应该被计算为一个FTR。
ü 即被EI维护又被读取的ILF仅计算一个FTR。
所谓“维护”，是指创建、添加、修改或删除一个ILF。
EI中识别DET规则：
ü 在EI的过程中，以用户角度识别的，通过应用系统边界输入系统内部的非重复的字段，那么该字段应算一个DET。
ü 如果在EI过程中，只要没有通过系统边界输入，就算它存在于系统内的一个ILF中，也不能算为一个DET。例如：
n 外贸订单系统中，订单的金额是被单价和数量自动计算的，那么金额是没有通过系统边界输入的，因此在EI操作中就不应该算做一个DET。
ü 在应用程序的EI操作时，系统提示的错误信息或完成操作的信息，应该被分别计算为一个DET。例如：
n 在网站注册用户信息时，由于输入错误系统会显示提示信息，那么这些提示信息应该被逐个计算为一个DET。当EI操作完成时系统提示并显示出来的信息，应该被计算为DET。
ü 在EI操作中如果遇到主外键的字段，应该算作一个DET。
EO和EQ计算FTR的规则：
ü 通用规则：每个在EO/EQ处理过程中读取的ILF和EIF算一个FTR
ü EO额外的FTR计算规则：
n 在EO处理过程中每个被维护的ILF算一个FTR
n 在EO处理过程中既被读取又被维护的ILF算一个FTR
由于EQ中不可能有维护ILF的操作，所以它一定没有和维护相关的FTR。
EO和EQ计算DET的通用规则：
ü 用户可识别的非重复的字段，进入应用边界并且指明处理什么，何时处理或处理方式，并且由EO/EQ返回或产生，那么这样的每个字段算一个DET。例如：
在报表中的每个字段都是一个DET。
ü 在应用边界内以用户角度识别的，非重复字段算一个DET。例如：
n 在报表上起到解释或备注作用的文字信息，不管它是一个字、一个词或一段话，都当作一个DET；
n 某种编号或日期，就算它被物理存储在不同字段中，但从用户角度来看是一个整体的信息，因此被算作一个DET；
n 在饼图中百分比和分类算作不同的DET。
ü 在EO或者EQ操作中，如果对系统进行输入或读取操作时，相同的字段只计算一个DET。例如：
n 在报表查询时，输入的字段在报表上也有显示，那么将算作同一个DET。
ü 在应用程序的EO或EQ操作时，系统提示的错误信息或完成操作的信息，应该被计算为DET。例如：
n 用户查询一个列表时被拒绝，那么拒绝的提示信息就算为一个DET。
ü 在EO或EQ操作中如果遇到主外键的字段，应该算作一个DET。
ü 如果在EO或EQ过程中，只要没有通过系统边界输入，就算它存在于系统内的一个ILF中，也不能算为一个DET。例如：
n 在公司发工资的时候，员工对应的状态信息被更新，但这个状态信息的更新是没有通过系统边界输入的，因此也不能算做一个DET。
ü 页面的标题等类似的信息不计算DET
ü 系统字段生成的记号不能被算作一个DET。例如：
n 页码、位置信息、时间、上一页、下一页等信息。
在对EI、EO、EQ中FTR和DET个数进行计算后，可以对照下一节中介绍的复杂度计算矩阵得到EI、EO、EQ的复杂度，进而得到其对应的技术复杂度调整系数。
8.2.5 功能点估算方法介绍
采用功能点估算表模板，根据功能模块分解方法进行功能分解，并计算出各功能模块的功能点，如下表所示：
功能模块分解（分解到2-3级）
功能点类型与数量
加权后的功能点数
一级模块
二级模块
三级模块
输入
DET
FTR
技术复杂度
输出
DET
FTR
技术复杂度
查询
DET
FTR
技术复杂度
内部接口
外部接口
工作办理
任务生成

3

0

0

0
3
21
任务查询

0

0

12

0
0
0
下户管理

0

0

8

0
0
0
系统管理
系统参数
业务类别维护
8

0

1

0
0
0
处理选项维护
6

0

2

0
0
0
合计

操作说明：
1） 结合功能点识别规则，对各功能模块分解内容计算“输入”、“输出”、“查询”、“内部接口”、“外部接口”的个数；
2） 明确每个“输入”、“输出”、“查询”所涉及的 “DET”、“FTR”的个数（若一个功能点有多个“输入”、“输出”、“查询”，则“DET”和“FTR”分别取平均值）；
3） 通过公式得出“输入”、“输出”、“查询”各自的技术复杂度系数；
l “输入”技术复杂度矩阵(系数范围:1.0~1.4)

1~4个DET
5~15个DET
多于16个DET
0~1个FTR
低
低
中等
2个FTR
低
中等
高
大于2个FRT
中等
高
高
说明：黄色表示：系数为1.0；绿色表示：系数为1.1；蓝色表示：系数为1.2；紫色表示：系数为1.3；粉色表示：系数为1.4。
l “输出”、“查询”技术复杂度矩阵(系数范围:1.0~1.4)

1~5个DET
6~19个DET
多于20个DET
0~1个FTR
低
低
中等
2~3个FTR
低
中等
高
多于4个FTR
中等
高
高
说明：黄色表示：系数为1.0；绿色表示：系数为1.1；蓝色表示：系数为1.2；紫色表示：系数为1.3；粉色表示：系数为1.4。
4） 统计功能点总数。公式如下：类型数量，乘以相应功能点类型权重，可以得到功能点总数。步骤如下：
① 每功能模块的功能点 = å (输入功能点数量*技术复杂度系数*权重+输出功能点数量*技术复杂度系数*权重+查询功能点数量*技术复杂度系数*权重+内部接口功能点数*权重+外部接口功能点数*权重)
② 加权后功能点总数 = å (每功能模块的功能点)
计算出来的功能点总数，就是项目的功能点规模。
8.2.6 编码工作量计算方法介绍
为估算项目的工作量，需定义单位标准功能点，针对本公司一个中级编码工程师(2.2级)，所需要的编码工作量（单位小时）。定义如下：
JAVA
0.5
Delphi
0.3
这里的数值反映了每个标准功能点对应的编码工作量，需增加（工时/标准功能点）度量项，收集历史项目的中级编码工程师实际工作量数据，形成基线值供新项目参考。
在估算出每个模块的功能点数之后，考虑到一些特殊模块，如代码重用比例、内部逻辑复杂等因素，必要时需对模块的功能点数进行调整。如下图：
功能模块分解（分解到2-3级）
功能点类型与数量
加权后的功能点数
逻辑复杂度调整点数
代码重用百分比
估算工作量
一级模块
二级模块
三级模块
输入
DET
FTR
技术复杂度
输出
DET
FTR
技术复杂度
查询
DET
FTR
技术复杂度
内部接口
外部接口
工作办理
任务生成

3

0

0

0
3
21
0
0%

任务查询

0

0

12

0
0
0

下户管理

0

0

8

0
0
0

系统管理
系统参数
业务类别维护
8

0

1

0
0
0

处理选项维护
6

0

2

0
0
0

合计

系数调整说明：
l 逻辑复杂度调整点数：一般只是在该功能的业务逻辑处理比较复杂的时候才需要调整，需写明调整理由，正常情况为0。
l 代码重用百分比：需估算每个功能模块的代码的重用百分比。
在上述工作完成后，即可计算出项目的编码和单元测试工作量，步骤如下：
1） 每功能模块的编码和单元测试工作量 = （模块加权后的功能点数+逻辑复杂度调整点数）× 0.5 ×（1-代码重用百分比）*（1+模块相应的单元测试工作量比例）
2） 编码和单元测试工作量 = å （每功能模块的编码和单元测试工作量）
8.2.7 估算过程描述
1） 由估算负责人组织项目组成员完成功能点的初步估算（包括：编码、单元测试工作量，并确定技术复杂度、逻辑复杂度、代码重用等）。
注：为了避免功能点估算的理解偏差，保证估算的准确性，在初步估算过程中，对于输入、输出、查询、内部接口、外部接口超出5个功能点的模块，应在《功能点估算表》的备注列逐一列举所识别的输入、输出、查询、内部接口、外部接口的明细。
2） 初步估算完成后，由估算负责人提交估算专家组评审和确认。评审和确认采用会议方式进行，由估算负责人向专家介绍估算的内容、项目的各种假设和限制条件。目的是邀请估算专家组对估算结果的合理性、完整性、正确性方面进行验证和确认。需注意以下内容：
l 需展示各功能模块和界面，并说明功能点类型、数量、代码重用等，供估算人员判断各估算值正确性（包括单元测试工作量）。
l 需阐述技术复杂度、逻辑复杂度，与估算人员共同讨论，最后确定值。
l 有疑问及时讨论，最终达成统一的估算。
3） 计算项目的编码和单元测试工作量。
4） 估算小组对最后的估算结果进行审核，并对结果达成一致。
8.2.8 工作产品
功能点估算表
9 项目总工作量估算
9.1 估算过程描述
1） 根据组织过程能力基线和典型项目性能基线，确定项目编码和单元测试工作量类型占项目总工作量的比例，则按照如下公式可以估算出项目总工作量：
项目总工作量= 编码和单元测试工作量/ 编码和单元测试工作量类型比例
说明：“编码和单元测试工作量”及其“占项目总工作量百分比”是估算准确度高低的两个关键数据，估算人员应对此慎重估算。
2） 其他各工作量类型的工作量
根据组织级过程能力基线和典型项目性能基线，采用类似的方法，可以确定项目其它各工作量类型的工作量。比如：
需求分析工作量= 项目总工作量 × 需求分析工作量类型比例
说明：其中项目工作量类型比例是在参考组织能力基线数据的基础上根据具体项目的特性而调整的。如：客户方面组织结构复杂，新技术的应用，第三方软件的选型和采购，组件重用，数据移植工作量较大等，都会在不同程度上影响调整结果。
3） 增加对项目组架构设计师、测试负责人在项目中的指导工作量
根据项目组的特点，由估算负责人视情况增加对项目组架构设计师、测试负责人在项目中的指导工作量。比如：
架构设计师指导工作量=项目组编码与单元测试工作量*10%
测试负责人指导工作量=项目组编码与单元测试工作量*10%
说明：具体计算方式由各项目的估算负责人确定，提交估算专家组审核批准。
4） 估算时需要注意单位之间换算关系：
l 1人月≈22人天
l 一人周≈40小时
l 1人天=8人小时
一般在项目工作量估算时，采用以小时为单位。
9.2 工作产品
估算结果
10 代码规模估算
根据组织过程能力基线和典型项目性能基线，确定项目总代码生产率（行/人天），再根据估算的项目总工作量（小时），通过以下换算公式得出：
代码规模 = 总代码生产率 × 项目总工作量 / 8
11 进度估算
根据阶段工作量和该阶段可能投入的人力资源确定阶段进度。阶段进度与该阶段投入的人员的知识和技能有关，在确定阶段进度时一定要注意到这个因素。使用Microsoft Project工具进行的进度计划安排估算，进度安排计划需要考虑的因素为：
l 估算的工作量结果，各类型工作量。
l 开发任务书（或合同）所要求的开发启止时间。
l 确定工作任务之间的依赖关系和关键路径。
l 项目组人力资源状况。
在PROJECT进度表中必须标明项目的各个阶段，及各阶段需要进行的任务，（任务的分解一般在三级以上，每个任务周期不超过3天，若遇确实没有办法分解的模块，必须说明原因），每个任务需要的资源、完成周期；在所有任务全部分解完成后，应使用Microsoft Project中的“甘特图向导”功能自动识别关键路径，关键路径需要在进度表中用红色标注，根据系统自动识别的关键路径和项目的实际情况，调整并确定关键路径，它将做为项目跟踪的主要依据。
Project 计划中各阶段的工作量之和应与各类型工作量估算值基本保持一致，但需要考虑该阶段投入的人员的知识和技能水平，计划总工作量和估算工作量偏差控制在10%左右。
12 估算差异分析
项目验收阶段，估算负责人组织相关估算人员在《项目总结报告》中对项目组的实际工作量、估算工作量进行差异分析，找出实际工作量与估算工作量偏差的主要原因，分析项目组估算的准确性，对估算过程提出改进意见。同时，需将项目的估算数据、实际数据及其差异分析相关资料提交组织过程数据库，供后续项目参考使用。
EPG每年）利用积累起来的度量数据库，研究不同类型、不同难度项目的实际工作量与功能点或代码规模等之间的关系，研究造成估算工作量与实际工作量差异的原因，研究不同项目各种类型任务工作量之间的比例，不断进行横向纵向的统计分析，使估算更加合理和准确。
估算能力分析的结论应反映到公司规程和组织软件过程度量数据库中，供后续项目参考使用。
13 度量
质量工程师收集估算工作量、估算数据与实际数据的偏差。
14 附录一：PERT法介绍
PERT法(Program Evaluation an Review Technique，计划评审技术)： 是50年代末美国海军部开发北极星潜艇系统时为协调3000多个承包商和研究机构而开发的，其理论基础是假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布。PERT可以估算整个项目在某个时间内完成的概率。所以，此方法多用于一些难于控制、缺乏经验、不确定性因素多而复杂的项目中。这类项目往往需要反复研究和反复认识，具体到某一工作环节，事先不能估算其需要时间，而只能推测一个大致的完成时间的范围。利用计划评审技术，可以把每个工作环节的不确定性及对完成该工作环节的信心因素加入其中，从而给出更有价值的信息。它的估算思路是，对每项活动都采用三个时间估算值，即：悲观值，最可能值，乐观值。
PERT估算过程：
1） 专家独立进行估算（无讨论/咨询），估算过程不应受外界压力（如作者对估算结果的限定）的影响，专家的个人估算表格详见《PERT估算表(个人)》。
PERT法对各个项目任务的完成时间按三种不同情况估算：
① 乐观时间(optimistic time)--任何事情都顺利的情况，完成某项工作的时间。
② 最可能时间(most likely time)--正常情况下，完成某项工作的时间。
③ 悲观时间(pessimistic time)--最不利的情况，完成某项工作的时间。
假定三个估算服从β分布，由此可算出每个任务的期望ti（即：期望工作量）：

其中：
ai；表示第i项活动的乐观时间；
mi：表示第i项活动的最可能时间；
bi：表示第i项活动的悲观时间。
2） 估算负责人搜集各专家的估算结果，并做汇总表。详见《PERT估算表(汇总)》。
l 平均值=AVERAGE (value1,value2,...)，多人对某项估算后的平均值。
l 标准偏差：每个样本数值与平均值的差的绝对值之和，除以样本个数。标准差越小说明所有数值越接近平均值。
3） 当估算偏差大于40%时，估算负责人应组织专家讨论偏差较大的需求项和假定，经过讨论后，各人对估算结果进行调整，并提交给估算负责人。如此不断反复，直至满足以下任何一项条件：
l 完成2轮估算；
l 估算结果收敛于一个可以接受的范围（偏差小于40%）；
l 所有专家拒绝对各自的估算结果进行修改。
4） 估算负责人负责汇集估算结果，确定对每项分解的需求项所需的编码、单元测试工作量（小时）。
l 关键模块单元测试工作量：因在估算表中已拆分为单独的估算项，不需要另做处理；
l 非关键模块单元测试工作量：在“相应模块的编码工作量”基础上乘以“非关键模块单元测试工作量比例系数”（由估算专家组确定），做为该模块单元测试工作量。
5） 估算负责人计算项目总的编码与单元测试的工作量。
6） 估算小组对最后汇总的估算结果进行审核，并对结果达成一致。
PERT法在公司之前的项目中运用尚少，与公司实际估算场景契合程度还不确定，具体的运用场景和估算参数等定义尚待完善。因此仅在附录中给出介绍，供估算负责人在必要时选用。同时，为配合PERT方法在公司内的应用与推广，初步定义了PERT估算表(个人)、PERT估算表(汇总)等工作产品，规范了数据采集格式。

15 附录二：功能点计算场景示例
1） 导入

把外部的文件(EI>=1)，如excel、xml等内容通过上传组件(EIF>=1)上传到应用服务器，经过相应的解析组件(EIF>=1)分解出合格的数据，保存到数据库表(ILF>=1)或者是应用服务器本地磁盘中去：
EI
EO
EQ
ILF
EIF
1
0
0
>=1
>= 1
2） 导出

① 仅仅导出显示页面上的查询结果
用javascript读取页面上的内容(E0)，传送到导出组件(EIF>=1)，解析后组成文件，通过下载组件(EIF>=0)传输到客户端。
EI
EO
EQ
ILF
EIF
0
1
0
0
>= 1
② 涉及查询的导出
根据界面上的查询条件(EI)到后台数据库表ILF (>=1)中进行匹配，查询出符合条件的结果集（EQ），通过相应的组件接口（EIF >=1）导出用户需要的内容。
EI
EO
EQ
ILF
EIF
0
1
1
>=1
>= 1

3） 上传
参看导入
EI
EO
EQ
ILF
EIF
1
0
0
>=1
>= 1

4） 下载
1) 如果从数据库中查询结果组成文件，传送到客户端，则参看导出的第二种情况
EI
EO
EQ
ILF
EIF
0
1
1
>=1
>= 1
2. 把应用服务器上保存的本地文件通过组件传送到客户端
EI
EO
EQ
ILF
EIF
0
1
0
0
>= 0

5） 增加
EI
EO
EQ
ILF
EIF
Remark
1
0
4
4
xxx
整个页面的所有输入框，当作一个输入。如果页面中有 tree、google suggestion 等，当作组件，内部接口。
EI(1):新增作为一个输入（每个保存定义为1个EI）

EO(0):新增无输出
EQ（3）: 3个下拉列表涉及到3个查询（每个SQL定义为一个EQ）
ILF（4）： 3个下拉列表的选项涉及3个表、保存的涉及1张表（每个表定义为一个ILF）

EIF(0)：未涉及到外部接口

6） 修改
EI
EO
EQ
ILF
EIF
Remark
1
0
4
4
xxx
整个页面的所有输入框，当作一个输入。如果页面中有 tree、googl